March 9, 2016 at 8:19 pm
Comments posted to this topic are about the item Building Better Software
March 10, 2016 at 1:33 am
The development teams often want to selectively choose which pieces they want to apply as both teams and individuals.
The management teams often want to selectively choose when to apply it as both teams and individuals.
It usually ends up an inconsistent mess with all to blame.
This is my experience.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 10, 2016 at 2:39 am
Gary Varga (3/10/2016)
The development teams often want to selectively choose which pieces they want to apply as both teams and individuals.The management teams often want to selectively choose when to apply it as both teams and individuals.
It usually ends up an inconsistent mess with all to blame.
This is my experience.
Ditto.
Cultural change is hard and it takes determination to drive change coming from the top. My experience is that any change that requires over 12 months is onto a loser
March 10, 2016 at 8:59 am
Like the saying goes: "Culture eats strategy for breakfast" and this needs to have the kind a passion behind it that management typically has for 'customer service' and other general business objectives.
March 10, 2016 at 9:34 pm
Internally we are using agile and Scrum techniques to try and improve software development.
But top management (and end clients) always fall back on the waterfall model and phase-gate approach.
This can easily lead to 'cowboy' or 'ninja' coding to satisfy project timelines, milestones and deadlines...
March 11, 2016 at 2:35 am
Not many are truly invested in process - management are usually the first to bypass it totally. :rolleyes:
March 11, 2016 at 5:57 am
I see a lot of people get frustrated when the process is incomplete - and it often is. I see a lot of people that will insist on sticking to a process even if it clearly doesn't work. Solid processes take time to build, and they take experience. I think where many "opt out" is when they feel like they can't get work done and if they don't get work done they'll explode. Understandable, no one wants to be stuck or stalled. All of that is a lead up to saying that I think it's less about cowboy than their world view, and their view is based on their experience and their own expectations. Don't know that's fair to call them wrong for valuing productivity/speed over process, but if you want different values, you have to show them you mean it and have room for emergencies lest you throw the Dilbert flag.
Where I think many fail is having a process forced on them instead of getting input from all, and from not running it in pilot fashion and then re-evaluating. Processes much more likely to succeed if the team creates it.
March 11, 2016 at 6:09 am
At my current place of employment we are working towards CMMI Level 2 which is a good thing. Coming from more structured companies the cowboy code here leads to all sorts of deadline issues, code issues, etc.
So far I've seen PM's and BA's, etc get on board but so few Developers want to get one board. Many of them see any idea of process as bad, and would rather re-invent the wheel each time in terms of how to do development.
March 11, 2016 at 7:38 am
Chord77 (3/11/2016)
At my current place of employment we are working towards CMMI Level 2 which is a good thing. Coming from more structured companies the cowboy code here leads to all sorts of deadline issues, code issues, etc.So far I've seen PM's and BA's, etc get on board but so few Developers want to get one board. Many of them see any idea of process as bad, and would rather re-invent the wheel each time in terms of how to do development.
So many developers like to pick and choose what processes they want to follow. It is a little embarrassing as a developer myself.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 11, 2016 at 8:34 am
Thoughtful article, Steve. I've been in my current job less than a year, so in fairness to my employer and colleagues, I really may not have an accurate view of how things are done here. That needs to be understood up front.
As much as I understand how things work here, I see a sincere desire to improve, but nothing like you've described. There's no metrics in place to measuring our process. At least none that I'm aware of. Far too many applications that the department I'm a part of, depends on applications written in MS Access of various versions. As far as I know, Access doesn't lend itself at all to good code/project management. Certainly from what I hear about some of the Access apps around here they were written 10 to 15 years ago by someone who took a course on Access or bought a book. He/she would write something up in Access and then he/she would leave later a few years later. Now whole offices are dependent upon Access apps that no one knows or understands. The struggle by people just to patch these apps is so high that I don't know of much development going on to improve by either re-writing those apps or buying some COTS product.
I'm on a group that's trying to introduce a new pattern to follow for software development of projects. We've adopted CMMI, because its in TFS as a project template and its the only one that's sorta like agile but still incorporates that magic term, "Requirements". Which actually brings me to ask, is the CMMI project template in TFS an agile project type of more of a waterfall project type?
Kindest Regards, Rod Connect with me on LinkedIn.
March 11, 2016 at 8:38 am
CMMI is not Agile nor Waterfall, it describes best practices which can be applied to either.
Another thing to remember is that the Waterall has feedback loops much like agile, but many orgs never did that.
March 11, 2016 at 8:39 am
Gary Varga (3/11/2016)
Chord77 (3/11/2016)
At my current place of employment we are working towards CMMI Level 2 which is a good thing. Coming from more structured companies the cowboy code here leads to all sorts of deadline issues, code issues, etc.So far I've seen PM's and BA's, etc get on board but so few Developers want to get one board. Many of them see any idea of process as bad, and would rather re-invent the wheel each time in terms of how to do development.
So many developers like to pick and choose what processes they want to follow. It is a little embarrassing as a developer myself.
Agreed, if development wants to be taken more seriously in the higher decision making process it needs to stop embarrassing itself.
March 11, 2016 at 10:16 am
Has anyone bought a CMMI DMM model and tried to do a self-assessment? I'm curious if this is worth the cost of the license and if the model can be used to assess the organization's data maturity without spending thousands more on training or consultants.
March 13, 2016 at 8:16 am
Chord77 (3/11/2016)
CMMI is not Agile nor Waterfall, it describes best practices which can be applied to either.Another thing to remember is that the Waterall has feedback loops much like agile, but many orgs never did that.
Thank you very much.
Kindest Regards, Rod Connect with me on LinkedIn.
March 14, 2016 at 7:08 am
"Cowboy Code" I like that. Oh, and cowboys can learn from the past.
Viewing 15 posts - 1 through 15 (of 27 total)
You must be logged in to reply to this topic. Login to reply