Where does 'doc specifications' end and 'role ownership' start?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.