Help - Technical team does not want to work in agile way

Question

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

Answer 1

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.

That being said, Scrum provides a tool to address things like this - the Retrospective. Here's what I would do, in your shoes.

1. For one Sprint, I'd back off and let the developers split stories how they want (sidenote - splitting stories is supposed to be a collaborative process between the PO and the Dev Team).
2. At the end of the Sprint, during the Retrospective, I'd point out the actual, practical problems caused by the lack of splitting. (Assuming there are any! If not, return to step 1).
3. I would ask the Team to help brainstorm possible solutions for the problems. Without any bias. Only if and after the Team fails to provide a workable solution will I present my suggestion of 'split the stories to be more granular'.

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.

Answer 2

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.

Answer 3

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:

TL.DR:

• 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).

Long answer (with some backstory)

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:

• if i dedicate myself to fix the entire module instead of a bunch of items at each iteration i was able to write smaller, more efficient and bug-proof code that still stand.
• with every full module i worked i was able to learn, define standards and best practices that made the interactions more of a transaction instead of a guess.
• even though i was painfully aware that if i failed everything would be over, in that time period i really felt motivated and quite satisfied with every module that went live. it wasn't just a moral boost, i felt happy with my work.

When things got good enough and we started to get more people the "let save the boat" methodology received some organic modifications:

• i needed to coordinate with people, so we developed a "always open for questions at any moment" policy instead of structured meetings.
• iterative deliveries ended up being replaced by full task deliveries, which improved the understanding of all the parts that interacted with it and were more bug-proof instead of a cyclical patch work.
• everybody understood that tasks took time to do right, instead of trying to fit them in an arbitrary time frame.

Now we're scrum in name, because it's only scrum unless it gets in the way of making things work.

what does this have to do with your team?:

your team seems to have somehow reached the same conclusions that i did, that atomizing generate more problems than what it may solve. so, what do you do?

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

Answer 4

You're assuming that you know what is best for the team without being on the hook to deliver the software.

I am a strong believer in agile methodologies and Scrum in particular. I fully support the iterative user story approach. With that said, there are tradeoffs to consider:

• If the team is either working on an existing product or is accustomed to working on existing products, they may be hesitant to work on something knowing they will have to refactor it later. It feels like they are wasting their time.
• It is common in many organizations that developers are expected to push out features quickly with a promise they can come back and "do it right" later, then are never given the time for that. If the team has experienced that, even at past jobs, they could be conditioned to not trust iterative development.

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.

So my advice is to talk to the team and understand their hesitation. See what you can do to help. Find if there is anyone on the team who has experience working iteratively who can be your ally.

Answer 5

From Developer Point of View

The example which you have used: 'Users Grid', with everything written in (search, filter, sort, add/edit users

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.

So maybe do a discussion with them and ask why they oppose. If reason is something like the above, change your method a little bit so both you and the Team can found common ground.

Answer 6

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.

So organize a meeting with everyone and discuss things. The purpose of this meeting is to understand each other and get to the bottom of the problem. Only then can you find a solution that works for everyone. Telling them you want them to work in a more Agile way won't mean anything to them unless they understand why it's needed.

The SM/Agile coach can mediate things and make sure talks stay at a proper, respectable level, but this needs to be a separate meeting, not part of the Scrum events. The retrospective is the place to have such discussions, but it's obvious from the OPs question that retrospectives aren't doing their job properly (the team goes back to their old ways the minute the SM isn't looking, there is opposition to the idea, and this has been going on for a long time, so much so that the OP has given up and is willing to work with mini-waterfalls despite the risk to the project and the customer). A separate meeting is extra signalling about the weight of the situation. People need to understand that "this arrangement isn't working out for everyone". Once people understand the weight of the situation, the problem is decomposed, and the root causes of the disagreement are found, only then can something be done about it. Otherwise anyone, on both sides, can perceive things like "it's because someone says so or wants so".

Answer 7

It feels a bit to me like both you and the team are missing the same point. It's not about what's easy to build or test, it's not about being incremental for the sake of it, it's about delivering the right value at the right time.

How are you currently approaching your sprint goals? You've mentioned prioritizing based on priority and value, but do you set clear sprint goals? Do you have clear business goals? Do you let picking the work flow from the goal that's set for the sprint, or is there just a giant backlog of stuff and you're just working your way down?

If it's the latter, I can imagine developers thinking the way they're doing now. If there's no real reason to deliver a thing now or next sprint, it's easier to bunch up functional areas and deliver fully formed new features.

But if there's a sharp goal, then at some point you need to talk "how will we reach this goal?" and you're going to realize you can't deliver all the non-essential side features to hit the sprint-goal, and everyone will realize hitting the goal is important and then you can have a discussion about splitting up components and building the important things first and the not so critical ones after the goal is delivered.

If there's no important goal to hit, then neither approach is better than the other because without the sprint goal, everything you're doing is essentially reduced to busywork and there's no best way to accomplish busywork.

Answer 8

When people are very resistant to change, it's often a protective behaviour and that's the most important Why? you need to ask.

My immediate reaction was that they seem to be building in a lot of auditing into the task, which you're perceiving as a mini waterfall.

When the team creates a new user manually in SQL, what else are they getting the chance to do? Are they worried about the implications of someone else creating users? Sometimes a manual procedure includes checks that are a lot of work to build in code.

You seem to be taking a common approach of dividing things into horizontal slices of functionality. It may be they have learned, very much the hard way, that leads to more bugs and other problems in the context of this code base.

There may be a political problem, or memories of such, in this organisation where they have had very bad experiences from delivering just a portion of an expected feature.

So, if you want to deliver incrementally, can you keep the same rich set of features but deliver simpler versions at an increment? Can the UI be drastically simpler?

functionality is easier to develop and test if it is incremental

Well, not always. Do you have direct experience with this domain or specific codebase which allows you to be an authority on this?

I loathe the term agile because it's very judgemental when you are telling people they are not being agile.

I've been a dev for nearly 40 years and as someone deeply interested in tools and techniques, observed the growth of incremental delivery and the birth of the Agile Movement. I've also worked on complex code bases, eg: 3D CAD of over 1M lines of C++. I prefer incremental delivery but also know it's not always appropriate.

Answer 9

Address Time-Boxing & Organizational Culture

The notion of "rework" is a tricky one when adopting iterative development methodologies. In traditional frameworks, anything other than one-and-done is treated as either a bug or a failure on the part of the development team. The reality is that agile frameworks embrace change, and a certain amount of rework and refactoring are a known trade-off for more frequent inspect-and-adapt cycles.

Ensuring that the whole team (and the organization it lives within) fully understands the purpose of time boxing, as well as the utility value of frequent inspections of both the product and the development/delivery process, is not the Product Owner's job. It properly belongs with the Scrum Master, supported by the parent organization and any coaches that may be assigned to ease the transition.

In short, many developers new to Scrum need to feel safe in adopting a development/delivery process that inherently promotes emergent design rather than big, upfront design (BUFD). As an empirical control process, Scrum entails an amount of overhead and rework that would trigger blame, finger-pointing, and adverse personnel actions in BUFD organizations. Until the whole team is confident that this will not happen, they will be justifiably skeptical of changing work patterns that have served them well in their career thus far.

A Deeper Dive: Reframing the Conversation

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.

Not chunking work doesn't delivery anything "right away." Then again, incremental and iterative paradigms often deliver slices rather than full-fledged features all at once. In either case, both sides appear to be talking around the fundamental question of whether the time boxing inherent in Scrum adds value to your current processes or product.

No one outside your company can really determine this. However, you should work with your agile coach to frame this differently from the current "monolithic vs. incremental" debate you and the team are having.

As the Product Owner, you are a member of the Scrum Team. That constrains how much authority (specifically, none over the Development Team) and influence (as much as you can provide) you have within the Scrum process. However, you are also the person who controls the Product Backlog. Keeping in mind your dual roles as both Product Owner and Scrum Team member can help you frame the conversation differently. In particular, you should:

1. Actively manage the Product Backlog to ensure you're prioritizing backlog items that (at least conceptually) fit within a single iteration.

2. Work with the Scrum Master and Development Team to set the expectation that the agreed-upon Sprint Goal must be completed within a single Sprint.

By framing the discussion as "What can we confidently fit into our next time box?" rather than "You should work incrementally!", you frame-shift the discussion from one about whether to work incrementally to one about how to slice up the work. Focus on what you need (e.g. a quick inspect-and-adapt feedback loop that can be demonstrated to customers as work-in-progress), rather than on how the team should accomplish it.

The Scrum Master and agile coach should work with you and the team to explain the business angle (if necessary), as well as offer some practical techniques if the team is struggling with time-boxed development. However, you and the Scrum Master must actively collaborate to ensure that the Development Team is afforded the necessary opportunity to rework and refactor as the Product Backlog changes.

Decoupling and decomposing features can be tricky, and will entail a lot of trial and error before the team gains the experience and process maturity to do it with even a 60-80% confidence interval. Unless the team is motivated (either self-motivated or externally) to put in that effort, and confident that they have a safe opportunity to learn by trial-and-error (with an emphasis on "error") without adverse consequences, simply adopting the trappings of Scrum will accomplish nothing.

Expecting success from the management fad du jour is a Dilbertism. Agile frameworks like Scrum are only effective when used by empowered and self-actualizing teams. Imposing an agile framework on unconverted traditionalists is a form of Buzzword Management™, and is the number one reason I've seen "agile" implementations fail. To succeed, Scrum must be embraced by the whole Scrum Team, the parent organization, and the customers/stakeholders/sponsors of the project.

Helping each collaborator within the process uncover the value proposition of the framework as it relates to their own skin in the game is not something you should have to do yourself. Lean heavily on your Scrum Master and others to make process adoption problems transparent and visible so that they can be constructively addressed.

Answer 10

(search, filter, sort, add/edit users, etc)

Just from a developer viewpoint:

• Showing a list without being able to add items is useless, so this is your first thing.
• The mask for editing an item will probably be the same as the one to add an item.

So this gives you the first sprint for CRUD functionality.

• Usually a keyword search is just another filter applied to the database query.

So it makes sense to develop the search and filter functionality together in the second sprint.

• Sorting can be on primitive types, then it is simple, or it could involve difficult algorithms, then it makes sense to do it in a seperate sprint.

That's how I would split the work, but I don't really see a point in delivering it after each sprint. It has to be potentially releasable, but doesn't mean you ship or review it with the customer. Look, we have a list. Oh look, now it can search. And now .. you still awake? Hello? I think most of our customers would suggest one review after the thing is ready. It's also a little awkward for us to present some small part of a functionality because everyone is thinking "that's all you did in a sprint?", much more fun to click through a full feature and show all the different things you can do at once.

From experience I don't think much will change feedback wise for a simple CRUD screen, maybe some design or layout aspects that can also be fixed after the first review. For bigger parts of the project it makes sense to split it up and get an early review, let's say the item management screen you describe, some other screen where the items interact or a report page where you can print stuff. Those are seperate entities and should be developed in seperate sprints.

It also depends on the technologies and platforms you use, how many people are involved in the development, their availability and how much coordination is needed to really finish something in a sprint.

You have to ask the team what would be needed to split the tasks efficiently and work from there. Maybe they need different working conditions.

Scrum also means they all work on one thing together, is this even possible? Maybe they need a blocker on other incoming projects. Maybe they need better tools?

Figure out the real problem and then solve it, together.