0

What is the Agile philosophy around the criteria for a groomed story and Tech team responsibility?

(I deliberately phrased the explanation as antagonistic for the sake clarifying the opposing viewpoints.)

The user-experience designer (UXD) develops wire frames for an epic (say, filling out a form). UXD considers all aspects that will go into the epic, to make sure all the features fit together (for example: display fields, validate, save, edit, delete - all occurs on one page). UXD attaches the wire frames to all stories that are dependent on it (each of those features might be one story).

Then the Dev Lead comes along and looks at a single story and says "the wire frame needs to be modified". Dev's concern is that (and I don't know where this quote came from) "any developer should be able to pick up any story and work on it immediately". Could UXD please remove the elements that are not relevant to the story in-question. (eg.: story X only covers display of fields, not edit or delete, so needs a wire frame that only has display, and not edit/delete.)

That's a problem, in my opinion. There is a lot more work to be done after the Business Requirements and wire frames are done. The dev team still needs to determine what those specs mean to them. It is on their shoulders to pull from the wire frame the specific implementation for this story. Wire frames are not Software Design Documents, and this is not a waterfall methodology, where everything spelled out in detail.

Putting too much in is a problem for Devs, but not putting enough in seems to be a problem too. Devs will not develop something that is not explicitly spelled out. E.g. If leaving a page is not explicitly called out to save data then developers will write functionality to take user to the next screen - and all the data is lost.

In other words, Tech Lead does not feel it is a Technical Requirement to prevent data loss. All requirements are Business Requirements. If business doesn't ask for it, they won't build it. (And therefore, the onus falls on Biz and UX to specify "PLEASE DON'T LOSE DATA").

It is my contention that the Dev is shirking their primary responsibility - which is to provide technically correct solutions for stories. Where I come from, every role owns their aspect of the product. Tech is responsible for saying "We will not lose data on my watch - and we don't need someone else telling us that".

It is my contention that the Dev Lead is stuck in a waterfall mentality - where they expect every detail to be documented and their role is to only build what is documented. but Agile Methodology explicitly calls for face-to-face collaboration, and working code is preferred over documentation.

But the Dev Lead has said explicitly that - if it is not in the wire frame, we will not build it. Where I come from, we call those people "code monkeys".

My question is: where is this line drawn? and what if the dev team is not open to negotiate where this line is (because they're too busy coding)?

6
  • Could UXD please remove the elements that are not relevant to the story in-question. -- So the UXD must provide individual wireframes for the title of this post, the body of the question, and each of the links below the question? No, I don't think so. Dec 12, 2018 at 20:02
  • If leaving a page is not explicitly called out to save data then developers will write functionality to take user to the next screen - and all the data is lost -- That developer is incompetent, no matter what the specs say. If something doesn't look right to me, I ask questions. Dec 12, 2018 at 20:04
  • Tech Lead does not feel it is a Technical Requirement to prevent data loss. All requirements are Business Requirements. If business doesn't ask for it, they won't build it. -- This is obviously absurd on its face. The whole point of modern agile methodologies is to prevent these kinds of software design failures and project catastrophes. If your process doesn't leave room to fix things like this, then your process is broken. Dec 12, 2018 at 20:07
  • So do you actually employ code monkeys, or are they professionals that have at least enough brain power to light up a bulb? Dec 12, 2018 at 20:09
  • Indeed. This is as I see it. Dev Lead does not seem to feel it is appropriate to ask questions. As I see it, questioning (otherwise known as collaboration) is core to Agile methodology. Dec 12, 2018 at 20:59

3 Answers 3

2

In an agile process, the line between the two is blurry. One of the biggest facets of agile is the developer closely working with the spec writer, asking questions, getting feedback, listening to requests and giving feedback. The requirements, in whatever form they come in, are expected to change. The developers need to be agile enough to deal with those changes. You need to pay these people by the hour rather than by the job for obvious reasons.

If business doesn't ask for it, they won't build it.

That's a failure to communicate. They want something more like a waterfall method where they actually have requirements they can meet. If they don't know enough about... the business model, the technology, the use-cases, the users (and on and on) then they won't know enough to start the conversation or to even think if... what was it? "if data can be lost"?

Don't say "stuck in the waterfall mentality" like it's some sort of insult. There are plenty of cases where a waterfall is superior to an agile process. Yours might or might not be one. (Also, it's a sliding scale between the two. Even for big hard contracts they sometimes shift the whole river a little.). If there's some sort of business ethos or software development plan where it's stated that you're following an agile philosophy, lean on that and ask him to be a little more engaged and to deal with ever-changing requirements.

Where I come from, we call those people "code monkeys".

Well certainly don't lead with that. No need to be an ass.

what if the dev team is not open to negotiate where this line is (because they're too busy coding)?

Then you have inter-party conflict and it's literally management's job to manage that. They should make it clear what the process is and who is responsible for what. Either you need to write a better spec or the dev team needs to be more engaged, have more meetings, ask more questions, and know the use-cases better so they can interrogate you for a better spec. But that's a decision for the boss. There's a reason they get paid, make them earn it.

3
  • 'Don't say "stuck in the waterfall mentality" ' To be clear, we are officially an Agile development environment, corporation-wide. There's no wiggle room there. And all roles are on-board., Only dev team (lead) has trouble. Just wanting to double-check that I'm not the one being the "rules lawyer" here. Dec 12, 2018 at 21:09
  • Perhaps the dev team (lead) originally came from a waterfall environment, an environment where he was more comfortable? Perhaps it might take some time to make the adjustment to cowboy... er, seat of the pants... um, agile development? Dec 12, 2018 at 21:19
  • That's almost certain, in my opinion. Unfortunately, Team Lead defends position vigorously. No adjustment going to happen if no attempt made. Dec 12, 2018 at 21:27
0

The way you write it does make the dev sound like they are being a bit picky. BUT!

A UX design whch has more elements on the page than are needed for the story is moving towards a waterfall process.

You should be able to release the product after each story is complete.

Lets say you complete the story and put the extra buttons on. Now you have non functional buttons. You can't release the product.

If you leave off the buttons that arent in the story then, for one thing you are making a judgement call and migh leave off the wrong thing and secondly you might have the story marked incomplete because the end result doesnt match the design.

More commonly though the implementation will force changes in the design. So you'll want to include those changes in the design for the next story.

With the non specified functionality, It does seem like a pernikity example, but yes generally you do need to specify what you want.

The idea is to move quickly and produce what the business wants, not what the developer thinks is cool.

They could easily go off, spend thousands on pounds on servers and sql licences and a couple of sprints writing that save functionality only for the business to say, oh thats not important for phase one. We just want a demo.

It sounds like your lead dev is used to working in a high pressure environment where they are getting paid to match the spec as quickly as possible. Rather than one where the devs are given a vague business idea and left to run with it.

You say you want the later style, where you expect the dev to fill in the blanks, but you also say you are having the UX guy do designs up front for whole sets of stories. Which gives the opposite message.

I would recomend you cut back massively on the spec and just make a working proof of concept first. forget about UX. Just give the devs basic vague stories and let them make it work.

Once that works and you are happy with the functionality build on it incrementally. This will enable everyone a base structure to start from when speccing features.

5
  • 'Lets say you complete the story and put the extra buttons on. Now you have non functional buttons." Just because wire frame shows buttons does not mean Dev should implement them. Story acceptance criteria says what should be built. Dec 12, 2018 at 21:01
  • There's a big difference between "what the developer thinks is cool" and "why the software doesn't work because the developer couldn't be arsed to ask obvious questions." Dec 12, 2018 at 21:14
  • does the "story acceptance criteria" say save the data when you navigate off the page? why do you expect them to add that, but not add the buttons? or a cool sparkely mouse trail? If something gets missed you just add another story, no big deal. Thats aglie
    – Ewan
    Dec 12, 2018 at 21:32
  • Because we go down a path of infinitely adding stories : 'well, you didn't SAY you wanted to KEEP the data the user just laboriously typed in, so we didn't do it'. So now we go into the next sprint - with more story points used up - and the feature still doesn't work. Dec 12, 2018 at 21:37
  • 1
    You keep saying that like no-one would ever want to seperate the data input story and and data saving story. But its not unusual.You are supposed to keep adding more stories after each sprint, its agile
    – Ewan
    Dec 12, 2018 at 21:42
0

Something to keep in mind from the team aspect, some form of "retrospective/course correction" will continue to occur no matter the methodology or the type of team as the team attempts to be more gelled. The concept of having a retrospective at the end of a sprint/time box is meant to review the process with questions like what you are asking here. As a team, it would be a discussion/review of what was done "well" and what was done "poorly". Doing something "well" or "poorly" is mainly subjective based on the team's viewpoint as a whole.

For the scenario you have, a piece that the Dev lead did, where I would agree is that if an epic/story has been pulled into a sprint, then new requirements should not be added to the story in the middle of the sprint. To your point on the story, if the requirement was clarified to state that while a user is traversing through an application the following screen, tab, page, or whatever relies on information from the previous section and data must persist, then the requirement is not "new" but a clearer definition. Getting clarification is not the act of getting new requirements, but the act of confirming/clearly defining the requirements given.

As far as the wireframes, the intent is to demo with customer/product owner to determine the look/layout and the potential flow(s) that can happen as a rough draft (flow meaning some sequence of events). Wireframes always have the potential to be modified, and wireframes do not completely define all areas of functionality. If a wireframe did define all functionality, then it would be the same as doing all of the work upfront just to pass it along to someone else to redo/copy.

Keep in mind that there may be some kind of policy, either at the team or company level, that is mandating that all of this information must be in the wireframe prior to adding any new/updated functionality in the codebase, but that would be a whole different discussion with people within that team/company.

To sum it all up, the line is usually defined base on the intent of the requirement. If it was clarified that the intent of a requirement includes X, then that is the responsibility of the Dev Team. If the given requirement doesn't have any bearing on the story/functionality, then that crosses the line away from the development team (not accepting to add the requirement to the story).

An example of a requirement with no bearing on the story/functionality:

Given some page, I (User) need to be able to add scheduling information for employees, and the submission should fail if there is a conflict. From the wireframe, all of the fields are defined, and how the notification/error message is presented has been decided.

During the sprint, the customer says that the page needs to have a table that shows the current employees schedules, so that users can reference the table instead of trial and error or using some other tool where they want to consolidate the process.

Although this requirement would help the customer utilize the page better, it has no bearing on whether the story, as a deliverable, will be accepted or rejected, and it would require each step from UXD to Dev team to be performed again.

2
  • Unfortunately, the rest of the group is in agreement that Dev team has a responsibility to create quality technical solutions. Which means we see this this is a conflict with Dev Lead directly, not an Agile issue. Dec 12, 2018 at 21:24
  • At that point, do you, or anyone else on the team, have quantifiable proof that the current process defined/driven by the lead is not sustainable with delivering in an iterative process, such as agile? Whether or not the proof is there now, it would be beneficial to start tracking that and use some kind of burn down/up chart to be able to present to the lead, or upper management, the reasons why the process needs to change, via turnaround times on work item requests, trends of the team velocity, and mapping/diagraming the full process used in each sprint. Dec 12, 2018 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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