[iamcj]

Hi,

I am a Product Owner for six months now, comming from the industry(electronic equipment) where my new company (200 employees) is creating software for. To make the switch to this new job I've studied programming and software engeenering for several years. The company creates complex new software. My team members are very divers in age and experience.

We create functional designs as a team and I let them review my use cases. Till that point it goes great, they give me great feedback.

But the design process stops there. They take use case 1, program it functional and then refactor it. Then they take use case 2, come to the notion they have to change 1. So they change one, introduce a bug, finish use case 2, fix the bug. Then they take use case 3, come to the notion they have to change use case 2, which leads to changes in use case 1, and so on. In this 6 months they created one sequence diagram because I asked them to. So no technical design, no class diagrams, no sequence, communication or state diagrams. After about a week in the sprint they start to ask me questions that tell me that they are zoomed in so far that they have lost sight of the bigger picture and have forgotten things.

Before I go and discuss this with my teamleader. Can this be a 'normal' programming style in your opinion? When I program something for my self, I devour a "ton of paper" before writing one line of code, but I consider myself an amateur. Is it just a matter of personal taste, or does every self respecting programmer first has to form an overview of what he will be coding and create some form of technical design for new functionality, no matter the circumstances.

Thanks for your time. I don't mean this in a bad way, I just wan't to make things better if I presume they can be.

Searching for an edit button . When I say change the use case, I mean the code for the use case.

[tlhIn`toq]

You've actually answered the question you posted at the title of this topic.
Personally I think it's clear you know this isn't right, and just need some confirmation.
Consider your suspicions confirmed.

Updates and refactoring are normal.... After the product has evolved, new features have been shoe-horned in that weren't part of the original design, etc.
But it sure shouldn't be that they are building for Use-Case 1 without even looking or planning for other cases. That's just bad/ignorant/student behavior.

Feel free to browse my blog here and my tutorials. You'll see a ton of places where I beat on planning, planning, planning... take a break... plan some more.

I also harp on how a developer should be able to see the places where the client has overlooked something.
Lets say the client wants the ability to upload a photo. The spec says 'a photo'. But as an experienced developer you should immediately see that 'a photo' will quickly become 'photoS' and that will become "media" meaning photos and video. If your team doesn't have even experience to make these kinds of observations and expectations you might want to re-examine the resume of whomever is leading them. Coders code the black box they are told to make. But the architect is god. If the architect isn't planning well, showing experience, or at the very leasing considering all the use cases before creating the blueprints for the software there is a problem.

[astonecipher]

I would say the diverse group of developers are all at the amateur/ college level, personally. As you said, you design a lot, before you start coding. So, they are either jumping to coding when they know better in some preconceived notion that this will impress you; OR, and this is the scary part, they really don't know what they are doing and need a project manager that can organize them better.

Either way, working on on story should not alter another, and if it does they should be interrelated. I would start by segmenting the process out. Start with the epic, then break that down into singular modules. During your [daily] stand-ups, findout what small task they have finished. If the task given takes more than a day, it either needs further breakdown or team members need to start being replaced.

[iamcj]

tlhIn`toq, on 14 December 2015 - 03:13 PM, said:

You've actually answered the question you posted at the title of this topic.

astonecipher, on 14 December 2015 - 07:09 PM, said:

I would say the diverse group of developers are all at the amateur/ college level, personally.

Wow, I am a bit "baffled" by your reactions. On the other side I am extra glad I aksed this question. Tnx. Do you have any suggestions on how to handle this situation without messing things up. I am 33 but a new be in the software business, some are programmers for more than 20 years.

@tlhIn`toq, I will look at your blog.

[jon.kiparsky]

Yeah, that much churn is a bad sign. And like our Klingon friend, I'm pretty sure you knew that before you asked the question. This doesn't mean that I'm telling you that you should use this design technique or that one or the other one. I don't care what sort of design documents you generate. Frankly, my team seldom generates any of that stuff. Instead, we meet once a week to discuss the tickets that are likely to make it into the next sprint, and we try to figure out how much work they're going to be, in points. When we talk about a ticket for a little while, and then agree on a number of points to put on it, that's usually a pretty good indication that we understand it.
But if you need design documents, that's fine. Whatever it takes, as long as everyone on the team understands the work that's coming up.

Quote

If the task given takes more than a day, it either needs further breakdown or team members need to start being replaced.

Hm. I'm not sure I like this approach. We typically schedule ~90 points for the three of us in a two-week sprint, so that's about 15 points per developer per week. And we're fine with taking on 13-point tickets (we use the Fibonacci sequence for our estimates, like many teams), which means that we're fine with tickets that take a couple of days or more. This works for some teams, and not for others, it's a "whatever works" sort of thing. But the latter part, about people being replaced - that's not a management style I'd go along with.
What this leads to is people who are timid, afraid to take on challenging work, because they're afraid that they'll be canned if they reach too high and fall. I want people to fail sometimes - if you don't fail, it means you're never trying anything beyond what you already know how to do. This means that if someone's having trouble, you work with them and help them get past it. Maybe you have them pair with one of the more advanced team members to figure out a way past their blockage, or maybe there's something else going on that's holding them up, or maybe you just accept that this person's going to be slow on this kind of ticket, so you give them more of them until they get a chance to get good at them. Or maybe it turns out that this dev is the one who's noticing the technical debt in the code and actually taking the time to clean up the campground, while someone else on the team is just making a mess and moving on. The important thing to remember is that developers, for the most part, want to do a good job, and if you help them get better at their work - by helping them learn new stuff, or by clearing obstacles out of their way, or whatever it is they need - then you're going to get the best work they can give you.

Maybe if it turns out that they're just hopeless, you fire them - but then you have to go back and figure out how they got on the team in the first place, and fix that. Because any time you have to fire someone, that means a lot of people in your organization have screwed up really badly, and really expensively.

[astonecipher]

Quote

If the task given takes more than a day, it either needs further breakdown or team members need to start being replaced.

I think this came out wrong. I don't mean to say go through firing everyone. I mean, if they cannot do their job, they need to go. Senior Developers should know what is required of them, just as Junior and mid level should. If a senior developer is not contributing, mentoring, or providing solutions however, there needs to be people in place to fill that role adequately. I have tickets that could take weeks to complete, but in those weeks, other code does not need changing to make the new feature work.

From the sounds of it, you inherited a group that was allowed to do whatever they wanted and need to be rained in.

Jon, your team operates that way, because everyone is striving towards the same goal. My team is the same way. We don't need someone over us telling us what to do, just that these tasks need completing.

[iamcj]

Today I think I found out why the team is like this. I searched the archives for technical designs, and I found many, the ones from the last two year al by one person who left a month after I came. So the rest are probably used to implementing his designs and they now just take mine and go with it.