Agile Methodologies - How Is the "Legalese" Handled?

[tompkin]

I am ignorant on the subject of Agile Methodologies with Scrum (or anything else Agile) so my semantics may be wrong in my question.

 

In my experience in the "Waterfall Method", each milestone was considered a legal contract. I am wondering how this is handled in Agile.

 

For instance, if you have a project that is anticipated to take 3 years you might have one milestone after the first year, one after the second year,  and the third milestone which completes the project. (Each milestone represents the stated requirements to get to that point).

 

If the development team is doing "sprints", how are intermediate goals handled from a legal standpoint?

[jamieakers]

It really depends on your specific implementation of Agile.  It's unlikely for starters you would use Agile to plan a 3 year project, you'd generally concern yourself with 1 year maximum (as based on this 1 years work it is almost certain what you do next year will wildly change).  From there you're at a point where you can breakdown the epic story you want to achieve by the end of the year into achievable bite-size sprints of a fixed duration.

 

With that in mind you'd generally have a document outlining the fuzzy "what we want to achieve by the end of the year" closely followed by (and drafted at the start of each sprint) "what we want to achieve by the end of this sprint".  Does that make sense and answer your question at all?

[tompkin]

It really depends on your specific implementation of Agile.  It's unlikely for starters you would use Agile to plan a 3 year project, you'd generally concern yourself with 1 year maximum (as based on this 1 years work it is almost certain what you do next year will wildly change).  From there you're at a point where you can breakdown the epic story you want to achieve by the end of the year into achievable bite-size sprints of a fixed duration.

 

With that in mind you'd generally have a document outlining the fuzzy "what we want to achieve by the end of the year" closely followed by (and drafted at the start of each sprint) "what we want to achieve by the end of this sprint".  Does that make sense and answer your question at all?

Yes, it does. It seems that what was once called a "milestone" is now a target to be sprinted to and then when you get to that target then the evaluation occurs at to what the next sprint is supposed to achieve. That makes sense.

One related question that occurred to me. Typically with the projects that I have worked on, user input (user support) for the project was a part-time job for them. (I know). At different times of the project, they would be more involved than at other times. 

 

During a sprint, are there usually users present pretty much continually in case questions arise at any time?  

[jakem1]

We try tp have a key user or business representative attend stand-ups.  That's often frowned upon but I think it's helpful as it simplifies communication and helps identify issues early.  It's also helpful to have that person attend sprint planning sessions.

[jamieakers]

Yes, it does. It seems that what was once called a "milestone" is now a target to be sprinted to and then when you get to that target then the evaluation occurs at to what the next sprint is supposed to achieve. That makes sense.

One related question that occurred to me. Typically with the projects that I have worked on, user input (user support) for the project was a part-time job for them. (I know). At different times of the project, they would be more involved than at other times. 

 

During a sprint, are there usually users present pretty much continually in case questions arise at any time?  

 

I work at a multinational therefore it's quite difficult to have "users" involved.  I suppose the closest we have is a Design Team who in-turn represent our target customers.  They're present at the initial sprint planning to help guide our direction and help us understand expectations from the end-user point of view.  We don't involve them at stand-ups; from my own past experience this often results in ever-expanding goal-posts.

 

The key point you're alluding to with Agile is that it's always right to involve the right people at the right stage (be that management, other teams or users).  We'll frequently ad-hoc meetings with individuals form other teams if we need to understand how another area of the product works so we can move forwards.

[tompkin]

Ever expanding goals we used to term "project creep". We tried to seperate "ever expanding goals" with unforeseen ramifications.

 

For instance, is the project expanding because the user has decided to add some niceties? or is it that during project implementation there are things that were not realized and then things needed to be added.

 

Strictly speaking, this is laid at the users feet because they are really responsible for seeing the ramifications but we tried to be reasonable about it. If they were adding new "processes" to the domain, it's hard to see all the ramifications right up front. We looked at it on a "case by case" basis whenever we ran into that situaion. 

[DevTech]

Agile is an umbrella term that includes a wide spread in methodologies calling themselves Agile.

 

A core concept is for a customer/stakeholder to be embedded with the team so there is never any divergence with business objectives and therefore no need for milestones since another core value is that when the stakeholder sees stuff he doesn't like, the "requirements" change on a dime. It prevents the "you gave me what I asked for but not what I needed" and keeps the stakeholder happy at all times so that there is always a trust relationship the budget is spent wisely. When the budget is burnt up, the project is ended with whatever was achieved and the stakeholder is happy that the best effort was done with the budget available. If the result isn't functional enough at the end, it is the stakeholder's job to find more budget. By definition, the project always converges to a success since the guy in charge of defining the success adjusts his expectations as it goes along.

 

Even if most projects played out like that, there is long list of project types for which Agile is simply not suited for and most Agile projects don't actually follow that pattern because it is boring and inconvenient to the business side and they don't have any scapegoat to blame if they get heat from higher up.

[tompkin]

I think it's good to have a full time stakeholder/user representative during the development process but what I'm having a hard time visualizing is how he could possibly know all the requirements in detail?

 

For instance, what if he is representing several user departments. He may have come from one of them and have a good idea of the overall processes of all departments but I would think he would be hard pressed to know detailed requirements in departments that were not his own.

 

How would he handle this?

[DevTech]

I think it's good to have a full time stakeholder/user representative during the development process but what I'm having a hard time visualizing is how he could possibly know all the requirements in detail?

 

For instance, what if he is representing several user departments. He may have come from one of them and have a good idea of the overall processes of all departments but I would think he would be hard pressed to know detailed requirements in departments that were not his own.

 

How would he handle this?

 

Always keep in mind it sometimes seems like there are almost as many types of Agile as there are people practicing it, but there certainly are a lot of variations. The orginal Agile was Extreme Programming which was well a bit extreme for most organizations so many watered down versions sprung up to better fit with existing methods which of course also reduces the value in just about every case when compared to Extreme Programming.

 

Anyways in terms of your question there are no formal "requirements" since you time slice a project into tiny increments. You are probably visualizing those increments as the little boxes in a gannt chart for a waterfall project which needs all the requirements spelled out in order to make those pretty boxes. It is "traditional" to use User Story index cards or Kanban boards etc to map out what is next but in theory no further. When you finish the tiny increment, you evaluate it, refactor it, maybe go in a different dirtection a bit. It's not really agile if it isn't flexible and plastic as it goes along although again there are so many variatons that some organizations that think they are using Agile are just in fact using a tiny variation on a time sliced waterfall. Once you leave Extreme Programming it is a Wild West of Agile Social Memes run rampant...

 

On your stakeholder guy, he is paying for it so if he wants to guess then it is his business but if it's large enough to involve several departments then they should all have a stakeholder on the team. They are not "representatives." They are part of the team. But you probably won't see this happening because most organizations find it more inconvenient the closer you get the Extreme Programming and vice versa. And of course now that Agile is a full on trendy meme eveyone just has to be able to "say" they are doing it even when it is completely innappropiate to be attempting it.

 

For example any saftety related software should never use anything but a strict Waterfall with rigid requirements and specifications. Or anything that is an expensive one shot such as a space probe. Or anything that needs innovation such as new product design for which iterating to nowhere is what will happen.

[Haggis Veteran]

On our last project we work to 3 different "phases" so three set out dates

 

we then had two week sprints to implement a set bit of functionality

 

It worked quite well