HWZ Forums

Login Register FAQ Mark Forums Read

How do software free-lancers protect from lawsuits when project fail?

Like Tree1Likes
Reply
 
LinkBack Thread Tools
Old 28-10-2017, 09:14 PM   #16
High Supremacy Member
 
Azzizz81's Avatar
 
Join Date: May 2001
Posts: 37,122
Short sprints are not just an impact to customer. In the ideal scenario of Agile projects, we can have sprint of any length, but in a vendor-customer relationship, short sprint while in your rationale presses on the customer to be firm and precise in their decisions will also be pressure on the delivery team to rush throughout the project. They are neither beneficial to both parties. You are looking at story points like they are indivisible, but I look at them elastically. One(1) story point is how many mandays? Soon you will find your customers asking you to justify every single story and discuss why you think it justify the story points your teams come up with. The shortage of points will in the end be a pressure on the vendor side because there will be more effort require to answer and justify. When that happens, you will start to doubt if the intention to use story points as a way to rein down on your customer is a good idea.
That happens, that's why a thorough impact analysis is needed to to justify the story points. But more often that not there are still many scenarios or technical difficulties that arise while executing which we did not think of during planning. So the effort estimated is really a lower limit.
Azzizz81 is online now   Reply With Quote
Old 28-10-2017, 09:22 PM   #17
Arch-Supremacy Member
 
davidktw's Avatar
 
Join Date: Apr 2010
Posts: 10,105
That happens, that's why a thorough impact analysis is needed to to justify the story points. But more often that not there are still many scenarios or technical difficulties that arise while executing which we did not think of during planning. So the effort estimated is really a lower limit.
Well if you are having good results with what you advocate, good for you. My personal experiences tells different stories. In the first place, when you tender for the project, your cost are mostly fixed. If it is your own company project, that is a totally different scenario.

Story points in a vendor custome relationship are just progress metrics and to give stakeholders and executors knowing which parts are heavy and which are lightweight features. The cost per story points are more or less fixed. Exhausting of stories points are just burn down to produce velocity and knowing if your teams moving. Never would I recommend them as enforcement feature in a project to rein either sides. It would be a lousy move.

The more you need to justify the points, the more time your scrum masters and tech leads will be losing in the project. Until we move into the quantum level, time is the fixed factor here, and losing more of them is the losing end on the vendor side
davidktw is offline   Reply With Quote
Old 28-10-2017, 09:29 PM   #18
High Supremacy Member
 
Azzizz81's Avatar
 
Join Date: May 2001
Posts: 37,122
Short sprints are not just an impact to customer. In the ideal scenario of Agile projects, we can have sprint of any length, but in a vendor-customer relationship, short sprint while in your rationale presses on the customer to be firm and precise in their decisions will also be pressure on the delivery team to rush throughout the project. They are neither beneficial to both parties. You are looking at story points like they are indivisible, but I look at them elastically. One(1) story point is how many mandays? Soon you will find your customers asking you to justify every single story and discuss why you think it justify the story points your teams come up with. The shortage of points will in the end be a pressure on the vendor side because there will be more effort require to answer and justify. When that happens, you will start to doubt if the intention to use story points as a way to rein down on your customer is a good idea.

My personal advice is never use story points as your measurement to control anything. They are vague in the first place.
Not really using story points to rein them in, but using the short sprint duration to timebox them.

Its good because if they do delay a decision/requirement, it will not in time for the next sprint. The project team will not be working on unclear requirements.

If they change a requirement during the current sprint, which they are not supposed to anyway, it's easier to justify that the brevity on time does not allow them to.

If they proceed but regret later, the work will already be done. It's easier to justify that the change should be a new change request.
Azzizz81 is online now   Reply With Quote
Old 28-10-2017, 09:37 PM   #19
High Supremacy Member
 
Azzizz81's Avatar
 
Join Date: May 2001
Posts: 37,122
Well if you are having good results with what you advocate, good for you. My personal experiences tells different stories. In the first place, when you tender for the project, your cost are mostly fixed. If it is your own company project, that is a totally different scenario.

Story points in a vendor custome relationship are just progress metrics and to give stakeholders and executors knowing which parts are heavy and which are lightweight features. The cost per story points are more or less fixed. Exhausting of stories points are just burn down to produce velocity and knowing if your teams moving. Never would I recommend them as enforcement feature in a project to rein either sides. It would be a lousy move.

The more you need to justify the points, the more time your scrum masters and tech leads will be losing in the project. Until we move into the quantum level, time is the fixed factor here, and losing more of them is the losing end on the vendor side


While coming up with the story points, the team will be breaking down the deliverables, contemplating the effort and activities that go into them. Its part of sprint planning that not only gives us mandays or story points, but in the midst it also uncovers hidden risks or edge cases. The benefits cannot be underestimated.
Azzizz81 is online now   Reply With Quote
Old 28-10-2017, 10:45 PM   #20
Arch-Supremacy Member
 
davidktw's Avatar
 
Join Date: Apr 2010
Posts: 10,105
Not really using story points to rein them in, but using the short sprint duration to timebox them.

Its good because if they do delay a decision/requirement, it will not in time for the next sprint. The project team will not be working on unclear requirements.

If they change a requirement during the current sprint, which they are not supposed to anyway, it's easier to justify that the brevity on time does not allow them to.

If they proceed but regret later, the work will already be done. It's easier to justify that the change should be a new change request.
While coming up with the story points, the team will be breaking down the deliverables, contemplating the effort and activities that go into them. Its part of sprint planning that not only gives us mandays or story points, but in the midst it also uncovers hidden risks or edge cases. The benefits cannot be underestimated.
Well, if what you have described is what you have been doing, not just what Ken Schwaber advocated, and it works for you, it's good, then you should keep doing it.

First of all, the "shortness" of your sprint is not specified here, perhaps you would like to clarify on how "short" is your sprint.

What I had shared are actual executions which we have tested out not working. I can agree sprint must not be too short, nor should it be too long. The comfort level of a sprint cycle is dependent on various factors ranging from reporting requirements by the client, stakeholders expectation of how often features are visible, the complexity of the project and its features, the competency of the vendor and its staff, the politics involved in the whole project and its stakeholders and the turn around time for features to be firmed.

However the usage of short sprint (yet to determine how short is the period here) while we are executing Agile projects, is what I deem as double-edged sword. Short sprint are taxing on the developers as well as the techleads and even the scrum masters, because they will need to be doing more intensive frequencies(not to be mistaken as duration) of grooming. It may not be feasible at times. Some things are done concurrently, like stories grooming, waiting for approval turnover and so forth, so those are fine.

The benefits of not waiting till things goes out of hands before the project stakeholders react is a well known understanding of what Agile project entails as oppose to SDLC. That is not the crux of why I'm against using story points as a way to steer the expectation of the customers. I'm against using Story Points is because they are vague measurement right from the beginning. Getting them right obviously seems to make things clearer for everyone, but to say it will be the customers' onus to ensure that their story points are well spent will be one side of the coin. It's in fact also just as important for the vendor to ensure on their side because one thing that never seems to failed in all customer vendor relationship is vendors are mostly at the losing end of a failed negotiation. So to be dependent on something as vague as story points and using story points as some sort of holding or negotiation tokens are bad.

In situations when customers realise there is a bounding factor placed onto the story points, how the customers will react is not laid back and accept it. They will react by scrutinising on your story points, and you wouldn't want that to happen. It's already tedious to ensure project is on track, development are done properly, do you want to spent extra effort to explain your technicalities to stakeholders whom are not proficiently trained in software development on why you decided that this particular feature is worth X points and why few sprints ago, something of similar concept is 75% of this story point, which you need to further explain on the differences in architecture, the differences of this versus that and then you need to submit for the technical steering committee to decide the differences between both parties software architects? You can decide if you want and enjoy these extra works, because this was what actually happened in some Agile projects I have participated.

We all have different experiences in our works, and so I'm not going to say what you advocate will not work, but just in my opinion based on what I have encountered, I don't see it as a good method of seeking consensus between the vendor and client relationship. That's all I want to share, if you have been executing with your advocation with success, then feel free to carry on. I don't see nor do I experience the same when my teams are executing on the ground, so I won't agree to using story points more than what they are set out for, basically just for superficial accounting purposes and when "things done properly", they end up as invoicing purposes.


Last edited by davidktw; 28-10-2017 at 10:53 PM..
davidktw is offline   Reply With Quote
Old 29-10-2017, 12:23 AM   #21
High Supremacy Member
 
Azzizz81's Avatar
 
Join Date: May 2001
Posts: 37,122
Well, if what you have described is what you have been doing, not just what Ken Schwaber advocated, and it works for you, it's good, then you should keep doing it.

First of all, the "shortness" of your sprint is not specified here, perhaps you would like to clarify on how "short" is your sprint.

What I had shared are actual executions which we have tested out not working. I can agree sprint must not be too short, nor should it be too long. The comfort level of a sprint cycle is dependent on various factors ranging from reporting requirements by the client, stakeholders expectation of how often features are visible, the complexity of the project and its features, the competency of the vendor and its staff, the politics involved in the whole project and its stakeholders and the turn around time for features to be firmed.

However the usage of short sprint (yet to determine how short is the period here) while we are executing Agile projects, is what I deem as double-edged sword. Short sprint are taxing on the developers as well as the techleads and even the scrum masters, because they will need to be doing more intensive frequencies(not to be mistaken as duration) of grooming. It may not be feasible at times. Some things are done concurrently, like stories grooming, waiting for approval turnover and so forth, so those are fine.
My sprints are a month long, which is too long IMHO. Short sprints have the advantage that the scope will be smaller. Which is also an advantage to story grooming. Globally the trend is moving towards shorter sprints of 2-3 weeks.

The longer the sprint, the more likely changes will occur. Which is fine if the changes go into the backlog but they usually don't.The project team will feel pressured to accede to these requests in the middle of a sprint, reworking the stuff they have completed. The schedule will usually not be adjusted for these scope changes because it can be hard to explain to customers why the developers can't change something seemingly minor to them.

If a shorter sprint does not result in the scope becoming smaller, these costs will be reflected elsewhere ie, more overtime, higher turnover, technical debt, etc.

These are signs that the project is mis-managed.

The benefits of not waiting till things goes out of hands before the project stakeholders react is a well known understanding of what Agile project entails as oppose to SDLC. That is not the crux of why I'm against using story points as a way to steer the expectation of the customers. I'm against using Story Points is because they are vague measurement right from the beginning. Getting them right obviously seems to make things clearer for everyone, but to say it will be the customers' onus to ensure that their story points are well spent will be one side of the coin. It's in fact also just as important for the vendor to ensure on their side because one thing that never seems to failed in all customer vendor relationship is vendors are mostly at the losing end of a failed negotiation. So to be dependent on something as vague as story points and using story points as some sort of holding or negotiation tokens are bad.

In situations when customers realise there is a bounding factor placed onto the story points, how the customers will react is not laid back and accept it. They will react by scrutinising on your story points, and you wouldn't want that to happen. It's already tedious to ensure project is on track, development are done properly, do you want to spent extra effort to explain your technicalities to stakeholders whom are not proficiently trained in software development on why you decided that this particular feature is worth X points and why few sprints ago, something of similar concept is 75% of this story point, which you need to further explain on the differences in architecture, the differences of this versus that and then you need to submit for the technical steering committee to decide the differences between both parties software architects? You can decide if you want and enjoy these extra works, because this was what actually happened in some Agile projects I have participated.

We all have different experiences in our works, and so I'm not going to say what you advocate will not work, but just in my opinion based on what I have encountered, I don't see it as a good method of seeking consensus between the vendor and client relationship. That's all I want to share, if you have been executing with your advocation with success, then feel free to carry on. I don't see nor do I experience the same when my teams are executing on the ground, so I won't agree to using story points more than what they are set out for, basically just for superficial accounting purposes and when "things done properly", they end up as invoicing purposes.

I am not sure sure how story points, like man-days have any purpose in negotiation except for trading of system features during development. They are mainly for accounting purpose but not just from a financial perspective. Its a way of tracking how much effort is being spent on a piece of work and allows us to evaluate which pieces of work are starting to slide. Identification is a start, further analysis needs to be done to find out why the schedules are not being met.

My projects haven't had the need to be inspected by a techincal steering committee yet, but yes I wouldn't want to go through that.

Its hard for fixed costs projects to be agile since users will always find it hard to make trade offs. But the vendor should not feel like they are getting a raw deal. If one can in good faith and expert judgment justify why a feature is X story points, and the customer disputes it, then either the vendor can choose to reduce it against his own judgement or stand by his opinion and let a third party arbitrate. If this was to occur there will never be a win-win anyway, just a matter of how much loss each party is prepared to accept.
__________________
Crushed ambitions.
Broken promises.
Shattered dreams.

Last edited by Azzizz81; 29-10-2017 at 12:28 AM..
Azzizz81 is online now   Reply With Quote
Old 29-10-2017, 01:33 AM   #22
Arch-Supremacy Member
 
davidktw's Avatar
 
Join Date: Apr 2010
Posts: 10,105
My sprints are a month long, which is too long IMHO. Short sprints have the advantage that the scope will be smaller. Which is also an advantage to story grooming. Globally the trend is moving towards shorter sprints of 2-3 weeks.
Well for my side, we have tried sprints between 1 week to 3 months. Each customer will require different length depending on their commitment level and also their corporate culture. So far, we have stabilise on 1 month as the starting point. Anything below it has shown to be too taxing and not beneficial for the workload across the whole project team. Currently my company have projects that each may run across multiple SCRUM teams, in order to ensure communication across a team remains in close proximity physically.

The longer the sprint, the more likely changes will occur. Which is fine if the changes go into the backlog but they usually don't.

The project team will feel pressured to accede to these requests in the middle of a sprint, reworking the stuff they have completed. The schedule will usually not be adjusted for these scope changes because it can be hard to explain to customers why the developers can't change something seemingly minor to them.

If a shorter sprint does not result in the scope becoming smaller, these costs will be reflected elsewhere ie, more overtime, higher turnover, technical debt, etc.

These are signs that the project is mis-managed.
You anticipated the longer the sprint, the more likely of changes if we consider all other things as constants. But the truth is they are not, even if you make your sprint becomes a daily cycle, you will still run into these issues. What you are describing is the corporate or I should say the Product Owner do not follow the Agile SCRUM methodology that tasks can only proceed till completion before the sprint ends, or be dropped if the requirements have changed or task is later found redundant in the middle of the sprint. They are not allowed be changed. Now your description that there exists changes that never get re-enqueue into the product backlogs, and I assume you mean changes are made during the sprint. If so, it is already a violation of the Agile SCRUM methodology. If that is indeed the case, then why should a shorter sprint makes things different ?

Suppose you can slot 100 points into one long sprint and shorter ones can only do 10. If 10% of the points always get changes, these 10% will also occur across 10 sprints. The only thing get hidden is because there is a shorter sprint and ends earlier, so those intended changes get overflow into the new sprint as new tasks. It's not really solving problem, just hiding them behind the process. The main culprit of these issues are agreement to the methodologies. Basically the customer do not want to follow the agreement and they feel if there is need arise that main sense to bend the rules, they will bend it. Hence I don't see how a shorter sprint will make it any better. This form of degradation to the methodology can only be made by making the customer understand that such interruptions can only bring harm to the progress of the project. They wouldn't care if it will harm the vendor assets. Unfortunately this is the realism we need to face.

This is where the experience of the PM comes in especially helpful. His job, along with the SCRUM masters, are to shelter such from trickling down. After all, we would expect the SCRUM masters and the PM to be more experience and taking up the responsibility to shelter the software developers from such political pressure. In the ideal world, all personnel skill sets complements and are competently (more or less) equal, but the real world is not. That is where consultants, PM, SCRUM masters stand the line.

I am not sure sure how story points, like man-days have any purpose in negotiation except for trading of system features during development. They are mainly for accounting purpose but not just from a financial perspective. Its a way of tracking how much effort is being spent on a piece of work and allows us to evaluate which pieces of work are starting to slide. Identification is a start, further analysis needs to be done to find out why the schedules are not being met.
You are right and that is where I'm explaining, story points are created from thin air to give the stakeholders a rough guide in terms of complexity of the tasks on hand. In this way, within the same sprint, one developer will not be task to do 10 complicated job as oppose to another doing 10 simple tasks. If you are a software developer, which I assume you are, you should know there is no perfect software engineering. Something deem as 10 points in the past, if you would to do it again in a different time, it might not be the same 10 points because your assessment changes based on the new information you are given or you are no longer the same developer compared to 10 months ago. The architecture of the system have grown across the months and from component to component, the added complexities, the fact you are more knowledgeable about the system and now you are able to give better estimate. All these changes your perception and also the perception of other developers, so the story points assigned are different. The point I keep on stress on is, I shall repeat again, STORY POINTS ARE VAGUE CONCEPTS CREATED TO ACCOUNTING PURPOSES. Don't use them for anything more, because they are volatile. Because they are volatile, they will backfire against you when you attempt to use them to constraint your customer expectations in how to *NOT* overly push workload down your throat. I hope you get this message loud and clear.

My projects haven't had the need to be inspected by a techincal steering committee yet, but yes I wouldn't want to go through that.

Its hard for fixed costs projects to be agile since users will always find it hard to make trade offs. But the vendor should not feel like they are getting a raw deal. If one can in good faith and expert judgment justify why a feature is X story points, and the customer disputes it, then either the vendor can choose to reduce it against his own judgement or stand by his opinion and let a third party arbitrate. If this was to occur there will never be a win-win anyway, just a matter of how much loss each party is prepared to accept.
I'm glad your projects don't need to go down that path. We have went down before and we know how painful and demoralising it can be. There are things software engineers know which the business counterparts don't understand no matter how hard they try. The worse of all kind of those whom thinks they know (partially), because they were once a software engineer (20 years ago) and they think they will understand it. WHen you try to explain the matter to them, they don't understand and they will exercise the simplest of all "put all onto the table and explain". That's where they will start asking you to explain how you arrive at 10 points of this story. Some are simple enough for idiots and some just need a clever software engineer to explain some jargons that they don't understand. I think you already can feel where this is going, it's rabbit hole you don't want to dig into and you don't want to keep opening cans and cans of worms, which you cannot manage outside of the technical realms.

You are right, it is hard for fixed cost projects to run Agile. Agile for some I have come across are just marketing gimmicks by the technical directors and departments to show to the rest of the company or competitors that they are into the Agile wagon. Yes, there are Agile elements in the project, so it's Agile. It doesn't matter if it is full of bandages, who cares, when the project is covered with a shiny chrome finishing.

There are successful stories of Agile, but it seems those are normally product based Agile by product companies. I seriously have not intimately come across vendor-clients Agile projects that are truly successful, just that the deliverables are met regardless how badly the methodology is run.

The best method I know that will be most effective to keep projects are on track and everyone is given a proper breathing space is business negotiation. Methodologies and regulations are just guidelines, and only works effectively when everyone on the ship is heading the right direction, and business negotiation is the way I know will work to steer the ship in the right direction. So we keep the managing counterparts in projects on close tab with the project execution, start the negotiation as soon as the direction deviates.

Agile in my opinion are more expensive than SDLC. Everything comes with a price, with SDLC the complaint is deliverables are different from expectation and only discovered towards the end of the project. Some geniuses think some set of rules and regulations installed will fixed the problem because everyone will play nice on the field, and we can suddenly be agile because the processes enforce it, but no one seems to suggest it could be a deal more expensive because now everyone need to be more tightly rein in, communication have to occur more frequently, meaning there are more ideals floating around and also more conflicts floating around. The optimistic side of things is as long as people are discussing or debating, things will eventually get resolved.

You know, Agile is not creating new ideas, it is just putting them down on paper and hence when someone kick off side, the referee can call foul, but who is the judge in the business relationship between 2 parties only ? It's all about give and take , and most importantly lets not F up the show and we both walk away with profit in the pockets.

Personally I'm not all in for Agile despite the department I'm is named after it. The common sense here is methodologies are just a set of rules and regulations. You follow it when it makes you more productive, and it's up to your discretion to exercise some smartness in how you work. The rein is seemingly obvious, but the one pulling it is in the shadow, you need to look beyond the shadow.

I can go on and on for this topic, but I guess it's rather moot. I'm just in the same cesspool as the rest.

What a complicated world we are in, but also exciting because chaos bring forth opportunities.

Last edited by davidktw; 29-10-2017 at 01:42 AM..
davidktw is offline   Reply With Quote
Old 30-10-2017, 01:32 AM   #23
Master Member
 
cwchong's Avatar
 
Join Date: Jan 2005
Posts: 4,113
If u r freelancing, the value of the project is likely nt too big an amt so just a clause should do

Tho tbh it really is managing expectations
If u have an acrimonious relationship with customers it would better to have a pm b/w u and the client
cwchong is offline   Reply With Quote
Reply
Important Forum Advisory Note
This forum is moderated by volunteer moderators who will react only to members' feedback on posts. Moderators are not employees or representatives of HWZ. Forum members and moderators are responsible for their own posts.

Please refer to our Terms of Service for more information.


Thread Tools

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are On