Hired Team Trial Gold Tool
Hilke Mcnally
Our industry-leading team of industrial-organizational psychologists has infused every aspect of the Codility platform with rigorously researched yet accessible assessment science. Our goal is to enable all Codility customers to succeed with evidence-based assessment practices.
Embrace the skills revolution with our innovative Engineering Skills Model, skill-mapped content library, and technical interviews designed with interviewer tools and standardized workflows to let data, not subjective impressions, drive your decisions.
I am a Product Owner on a Scrum Team whose developers do not want to embrace work in an agile, incremental fashion. Simple example: the customer currently has to contact us to create users each time so we run them directly in SQL as there is no UI. This happens many times during the day. Occasionally there are other requests, like resetting the password for a user. When it comes to developing new features, they insist to have a Backlog item called 'Users Grid', with everything written in (CRUD operations, business logic operations like reset passwords, get related users, etc), and we deliver the users grid in one go with all the functionality; whereas I want to have separate backlog items, one for each individual functionality I just mentioned, and deliver items incrementally over a number of Sprints according to priority and business value. So for example we first deliver the Users grid providing CRUD operations (that would hit the biggest customer pain point quicker) and then deliver the other features in subsequent sprints.
My rationale is that functionality is easier to develop and test if it is incremental; it reduces risk, we can showcase things earlier to the customer and get feedback earlier. Whereas, to them, it's easier if we do not chunk up work and deliver things complete right away.
I fear we are ending up with a lot of mini-waterfall projects and I have tried everything to get them to move away from this approach; I rather suspect it's the team leader's lack of experience that is shaping the team in this fashion. We also have an agile coach on hand who is supposed to help the team embrace this way of working, but the minute he's not looking we're back at this.
I tried to communicate this countless of times, but each time I am met with blank faces and opposition. I have arrived at a situation where I'm tempted to let them work they way they want so that they learn from the mistakes, which I am sure they are going to crop up. But I'm worried the project, and customer, will suffer. I have never had these issues in the past. Am I missing something? Any ideas what else I can try?
(I come from a development background and advanced in roles between development and project leading over the last 20 years, so i do understand some of the comments from developers below. I evolved into a PO role on a natural transition because i was spending a lot of time dealing with customer requirements, so i appointed a technical team lead to focus on the technical/team issues while i focus on the customer.)
You don't make any mention of a Scrum Master in your Question, so I'm going to assume that either s/he doesn't exist or isn't helpful. If not, make sure you involve the Scrum Master! It's his/her job to address process issues.
Remember, agile isn't about avoiding problems. It's about finding them quickly. Don't be so hung up on following agile to avoid potential future problems that you avoid the cornerstone of agile itself - attempt, inspect, adapt.
That is a frustrating situation Chris. From your question, it doesn't sound like the team can't develop things in smaller pieces, but rather that they won't. I base this on the fact that it sounds like when the agile coach is there they do and just in my experience as a developer, the type of splitting you are talking about isn't usually difficult.
In short, you don't have an agile or technical problem, you have a people problem. To solve that people problem, you need to understand why the team chooses to build their features this way. I would hope that your agile coach or scrum master could facilitate that discussion, but I thought I'd give two possibilities below just to get you thinking. Be careful though, these are both just possibilities. The only way to know if it's one of these or something else is to have a good conversation with the team.
Possibility 1: You're stepping on their toes. People are easily insulted and technically, Scrum says explicitly that no one can tell the development team how to do their work. The situation you're talking about is a bit of a grey area, but still, it's completely possible that someone else telling them how to break down the work is heard as "you don't know how to do your job."
Possibility 2: Their way of doing it is a little more efficient and they think you're going to ask them to just do them all anyway so they are taking the path of least resistance. In these cases, they might be right or you might need to present them with a different scenario, where you just want add and view across 4 or 5 areas first before the rest of the functionality.
Like I said, there are many more possibilities than I can list. These are just a few to get you thinking along those lines. Hopefully your SM or agile coach can facilitate a good conversation on the topic.
I'm a developer working with legacy code on scrum, and let me tell you, i think they're right in their ways, because i do the same. Let me explain my case, be aware though i'm what people consider a cowboy/hacker programmer:
breaking everything on smaller items isn't good, you're missing on patterns & interactions: you're exchanging the chance of having a factorized code for multiple specific functions that overlap and can be factorized later (never). That's how crappy software is born.
you're focusing on the method instead of the result: if their way works, the quality is good and the bug count is low, as a PO, what's wrong? you need to let the specialists do their specialty as they see fit. you can't force people to change their methods because you don't like them. That's how terrible managers are born.
Moral-wise its better to work on a big project that has an end instead of the endless grind of smaller items: like the workers on the ford factories suffered, scrum is quite soul breaking and demotivating with his endless cycle of new small items that are never a full product. That's how the high Turn-over rate is born (citation is needed).
We have a software solution, written over the years in a niche language and spamming 1m+ lines of code distributed on hundreds of different modules and applications.So every time the client/PO/somebody asked "why don't we do this little functionality here?" and the scrum master atomized it beyond recognition we introduced new interaction bugs which were quite difficult to solve. The endless cycle of meaningless small task, constant bug fixes that could have been prevented and not feeling motivation to make something good gradually made our developers move on, until we ended with only one: me.
When it was obvious i was gonna be the last rat on the boat (a boat i still like mind you) i did something stupid but necessary: i studied the ENTIRE code base.when eventually i became the only who could work on items i implemented the most efficient way to fix things: told them to f*ck off, i'll do thing my way, with my own priority list and if they didn't like it they could fire me and go under in a month.
First i ditched the meetings because i was alone, i didn't needed to give explanations nor coordinate with anybody. Then i ditched the iterative delivery model because i didn't needed to show progress and half-working software was useless here. Then i ditched the sprint because i wanted to delivery a quality product fast so i took my time to make it right from the get go. And with that i found some really neat things:
There's a lot of different ways to do something, and each person/group has a way that work best for them.lets be clear, the only reason i wasn't fired and ended up hated by all my coworkers it's because what i did worked (at that time they kinda hated me a little though); but that's true for scrum and any methodology too: it is applied only because it bring results we're ok with.if their way of working delivers good results and your bug count are under control, why would you want to change it? because it's not the way you like it? that sound a lot like what a terrible manager would say instead of a PO.
If your role is PO then your only task is telling them what you need/want in your product, not how to do it. if what you want is a product made the way you think it should be done then you're not a PO, you're just a bad manager in PO's clothing
Iterative development assumes a low cost of change. Iterative development is all about refactoring. If you are refactoring every day, you're doing it right. But if you're constantly refactoring, then aren't you going to spend all your time regression testing? Agile works well when you can simply change the code, run the tests, and be confident you didn't break anything. The team has to experience that in order to believe in it. And it is extremely difficult to bake that sort of testability into an existing product.
To achieve the above, many frameworks provide built-in tools (i.e. Yii2 Gii) and will generate the grid in a matter of minutes. Now if you want to break it out then it will require more time because the developer has to go in and remove the feature and later on re-add it. It will be frustrating to go through that method.
What you have here is a disagreement. You prefer doing things one way, the technical team prefers their way. So the way to fix this is to ask WHY?. And not just why they prefer their way, but also why you prefer your way.
Maybe they are set in their ways, and you are set in yours. Maybe they don't understand all this Agile thing and don't see the point. Maybe Scrum seems dumb. Maybe they don't like the way you split the stories. Maybe you are actually bad at spliting the stories. Maybe they have some insight into the product and think it's better to do things their way. You are the PO but maybe you should be more open to their feedback. Maybe they are not very skilled technically and they are worried that they will make a mess of things by not knowing how to split work properly, to allow for incremental development, so they try to keep everything together. A lot of "maybe"s because I'm trying to guess what's happening simply from what has been posted here, but I'm sure you might have made similar assumptions before reaching a conclusion and asking this question.
b1e95dc632