With this contrast a perception has formed that we build the Rolls Royce of software which may be overkill for their needs.What they are really saying is they may not require the level of quality we have built into the software and may be willing to compromise on quality.Throughout the course of the project, we have been trying to educate the business on the benefits of these approaches, with limited success.It's obviously very difficult to prove the benefits objectively to non-technical people, and there's absolutely politics at play.I doubt very much this is a unique situation. Has anyone had any success managing this scenario and how did you go about it?
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
I can actually see where management are coming from on this one. I went on an itil course where I was challenged by the question - if you went to a hosting company and specified an uptime of 99% would it be a good thing if they delivered 100%. We all said yes but when the instructor explained the costs involved in that extra 1% and how either they are passing that cost onto you the customer or they will soon end up broke.
Management have mistakenly attributed this same approach to your work. They feel that without all of the inbuilt quality the costs could be even lower. This is the false economy because building quality in is far cheaper than fixing it later.
If this were me I'd start banding around pseudo agile terms to get their business. Suggest that your iphone app was developed with 100% code coverage in order to benchmark quality and the next projext will be delivered with 75% to reduce costs. Give them a higher estimate with 100% and the real one with 75%. Once you get the business no one will care when you exceed expectations. how many successful profitable projects before all the politics swings your way?
--
If this were me I'd start banding around pseudo agile terms to get their business. Suggest that your iphone app was developed with 100% code coverage in order to benchmark quality and the next projext will be delivered with 75% to reduce costs. Give them a higher estimate with 100% and the real one with 75%. Once you get the business no one will care when you exceed expectations. how many successful profitable projects before all the politics swings your way?
Your probably right, you usually are. I think, however that management are just looking to save hypothetical costs rather than judging on the success.
Maybe a more appropriate solution would be to isolate areas of future projects where they expect rolls royce quality and suggest your team work on those. There are invariably features of a system that business will not want to scrimp. Once you deliver your features on time and on budget the other teams will want to learn from you.
David
First, it's their money. Ultimately, the business retains the right to pay for the defect level they can live with.
Im juat not sure that stats and data on software processes are the key to constructive dialog. Its the success that counts. you have a successful project so you should be building on that. However you go about it don't let a successful team become a worse one.
Your probably right, you usually are. I think, however that management are just looking to save hypothetical costs rather than judging on the success.
Maybe a more appropriate solution would be to isolate areas of future projects where they expect rolls royce quality and suggest your team work on those. There are invariably features of a system that business will not want to scrimp. Once you deliver your features on time and on budget the other teams will want to learn from you.
Management likes to feel like they are in control, but the reality is they have absolutely no idea how we do what we do. Tell them what they need to know to feel in control, but never appologize for doing or ask permission to do quality work.If you were an artist would you put your name on something that just sort of sucked? If you were an author would you publish something that was almost spelled right? Nonsense.
Im juat not sure that stats and data on software processes are the key to constructive dialog. Its the success that counts. you have a successful project so you should be building on that. However you go about it don't let a successful team become a worse one.
you, sir, are hired! (too bad i'm broke.)
I do feel that the strongest argument in this case is that a team want to build on their success. They have obviously worked well together and acheved something they are proud of. Suggest that the high degree of confidence in the product motivated the team to work harder on it all the way through. You guys obviously want to work this way again.
The biggest issue for politics here would be if your approach bashes the non-agile teams more than emphasises your achievement.
Good luck!
Good response Ron, I especially like:"If this didn't work, I'd kill one of them as an example to the others."
The only thing that niggles me is the feeling that I'm not sure that trying to explain to management why we work the way that we do is productive: I think that this reinforces their underlying belief that they have the right to tell us how to do our work because they know better than we do. This Taylorist model of thinking is completely inappropriate to us as professionals, and is an example of the meta-cognitive bias called the Dunning Kruger effect[1] (they don't know what they don't know).
I think @Caio's point about professional standards is really insightful too, clients don't try and tell their doctors or lawyers how to do their job, and if they do, they get short shrift (try telling your surgeon next time that you're in hospital that he doesn't need to wash his hands, after all you're both in a hurry...) We need the courage to stand up for our position as professionals, which is why 'courage' is one of the five Scrum values and one of the five XP values too.
Avega Group
switchboard +46 40 10 51 00 | direct +46 40 10 51 31 | mobile +46 72 5150 121
Gustav Adolfs Torg 45 | 211 39 Malmö
Homepage: http://www.avegagroup.se/
Twitter: https://twitter.com/tomasmalmsten
Blog: http://www.tomasmalmsten.com/
LinkedIn: https://www.linkedin.com/in/tomasmalmsten
Before the money comes the craftsman.On 24 Apr 2013, at 20:16, J. B. Rainsberger <m...@jbrains.ca> wrote:First, it's their money. Ultimately, the business retains the right to pay for the defect level they can live with.Try to ask a doctor or any engineer to do a crappy job in order to reduce costs. Engineers can change product's materials to cheaper ones, they can change product's final characteristics, but they don't change their level of attention and their process of doing things the way they think it's right. Doctors can perform simpler or different procedures by patient request, impacting somehow on the final result, but the attention, caring and cleanliness will be the same.
If the client/patient/customer/employer insists, they act professionally saying "No, I won't do it, find another person to do it for you". Obviously, in the software field and in an employer-employee situation this is very hard to do. We are not used to act like that.
Technical discussions with client/customer/employer, if there has to be any, should be around tools, frameworks and user interface, i.e. the details in the architecture and their impact in the visible quality to the user (performance, interface).
Hi David,
Yes, management's statement gives me concern as well. I'd be inclined to play the cards I have, rather than start making up stuff. It's too hard to keep track.On Apr 24, 2013, at 5:02 PM, David Wilde <djw...@gmail.com> wrote:Your probably right, you usually are. I think, however that management are just looking to save hypothetical costs rather than judging on the success.
I would begin my conversation with them by asking them if they want more bugs. I'd be surprised if they did, but I'd be prepared to ask what bugs they wanted. I really don't think they'll want to go down that path. I would point out that we can't choose where the bugs go. They go in randomly … if anything it seems they go to the worst possible places. I would point out that it takes longer to find and fix a defect than it does to prevent it with tests. So if we back off on testing, we'll slow down rather than speed up. […]
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsub...@googlegroups.com.
To post to this group, send email to software_craftsmanship@googlegroups.com.
Hello everyone,My team has been involved in developing an iPhone application using Agile methods with a very high degree of test automation.We have successfully delivered the project with a minimum of defects and we are proud to have accomplished this.The business manages a number of other software projects outside of our team, not using Agile methods, have a lot of defects and a lot of manual testing.With this contrast a perception has formed that we build the Rolls Royce of software which may be overkill for their needs.What they are really saying is they may not require the level of quality we have built into the software and may be willing to compromise on quality.Throughout the course of the project, we have been trying to educate the business on the benefits of these approaches, with limited success.It's obviously very difficult to prove the benefits objectively to non-technical people, and there's absolutely politics at play.I doubt very much this is a unique situation. Has anyone had any success managing this scenario and how did you go about it?Thanks, Matt
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.