Anyone use this Agile Modeling site as a reference for how to do Agile?
-
An Introduction to Agile Modeling[^] If so (or if not and you peruse it) - I have a lot of pennies for your thoughts.
Latest Articles:
16 Days: A TypeScript application from concept to implementationInteresting! I've been thinking about doing some Agile/Scrum certification. Scrum was mentioned in every job interview I've had, mostly in "we work in Agile/Scrum teams, are you familiar with Agile/Scrum?" Just saying "yes" and seeing how they do things is usually enough, but there's quite a bit of theory too. It's especially fun to see how every company does it differently or how teams do it, but management doesn't (even though they say they do). I've been in a Scrum team with tight deadlines, but no planning because "we're doing Agile" (thus spoke management). I don't think certification would hurt on my CV. To answer your question, I don't know the site, but I bookmarked it. On a somewhat related note, the same is true for DevOps. It's like teenagers and sex, they all say they do it, only a few do and those that do it aren't very good at it.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
An Introduction to Agile Modeling[^] If so (or if not and you peruse it) - I have a lot of pennies for your thoughts.
Latest Articles:
16 Days: A TypeScript application from concept to implementationNot specifically that site, but I've practiced agile at a few different companies, and the one that was most successful was essentially using the model on your suggested site. The key phrase from the page you referenced is "
Quote:
Agile Modeling (AM) is a collection of values, principles, and practices
" in other words, it is a culture, and that culture is must effective when it is embraced by the whole company. Vertical buy in, as well as, cross department buy in to the process is key. I will take my penny now. Please make it a 1942 Lincoln wheat penny (with the error). :)
“The palest ink is better than the best memory.” - Chinese Proverb
-
Yes, but... ;p If the project is big enough, a single person won't be able to develop and/or maintain it. Because a single person only has so much time and can only know so much. Also, a single person on a project is a liability for the client, because if something happens to this single person the project could suffer major delay or could even get inaccessible altogether. So let's assume that you need at least a couple of people on a single project. And now, what you say, to each their own, is a major problem, because what works for you may not work for me, but we still need to cooperate as a team. And that's where agile comes in, it's a methodology that, in theory, should make it a lot easier to manage all of these people[^] and make them work together more or less successfully :)
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Quote:
a single person on a project is a liability for the client, because if something happens to this single person the project could suffer major delay or could even get inaccessible altogether.
I was on a project that was immense in scope with lots of DLLs for each of the supporting elements including one that was a built-in language interpreter, network messaging (pre-internet) another to make automated telephone calls, another set of DLLS, each for a different terminal emulation, etc. Thousands of lines of code with just me, at one point, to support it all! I had probably written a good 50% of it myself. My boss, the company owner, president, CEO and general tyrant had a $1,000,000 "key employee" insurance on me which I only found out about when the company accountant complained how much it cost after he increased it to $2,000,000 for subsequent years. My code brought in several million dollars to the company so I was safe from being murdered for the insurance for a while at least!
- I would love to change the world, but they won’t give me the source code.
-
Yes, but... ;p If the project is big enough, a single person won't be able to develop and/or maintain it. Because a single person only has so much time and can only know so much. Also, a single person on a project is a liability for the client, because if something happens to this single person the project could suffer major delay or could even get inaccessible altogether. So let's assume that you need at least a couple of people on a single project. And now, what you say, to each their own, is a major problem, because what works for you may not work for me, but we still need to cooperate as a team. And that's where agile comes in, it's a methodology that, in theory, should make it a lot easier to manage all of these people[^] and make them work together more or less successfully :)
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
I agree there needs to be a way to manage people with different styles but the main thing is communication. If you try and put everyone in the team in a size 32 shirt then for some it will be a good fit for others not. I've managed teams and I gave everyone a responsibility but let them do it their way. 5 developers and at a time when all there was was sneakernet. :)
They call me different but the truth is they're all the same! JaxCoder.com
-
Quote:
a single person on a project is a liability for the client, because if something happens to this single person the project could suffer major delay or could even get inaccessible altogether.
I was on a project that was immense in scope with lots of DLLs for each of the supporting elements including one that was a built-in language interpreter, network messaging (pre-internet) another to make automated telephone calls, another set of DLLS, each for a different terminal emulation, etc. Thousands of lines of code with just me, at one point, to support it all! I had probably written a good 50% of it myself. My boss, the company owner, president, CEO and general tyrant had a $1,000,000 "key employee" insurance on me which I only found out about when the company accountant complained how much it cost after he increased it to $2,000,000 for subsequent years. My code brought in several million dollars to the company so I was safe from being murdered for the insurance for a while at least!
- I would love to change the world, but they won’t give me the source code.
-
I agree there needs to be a way to manage people with different styles but the main thing is communication. If you try and put everyone in the team in a size 32 shirt then for some it will be a good fit for others not. I've managed teams and I gave everyone a responsibility but let them do it their way. 5 developers and at a time when all there was was sneakernet. :)
They call me different but the truth is they're all the same! JaxCoder.com
Agile is a lot about communication, but not just with the team, but with the business and stakeholders as well. I think the biggest lie of agile and scrum and everything is that "everybody should be able to do anything." At my last job they fired all Dynamics CRM people and told me "you do it because we're a scrum team." What the hell, I'm a developer! I never touched CRM in my lifetime and you just fired people who had years of training and experience! It's not only not possible to know everything, but in practice coder 1 will write modules A, B and C and coder 2 will write modules D, E and F. They could take over each other's code, but it'll be slow and painful. At least they'll know what the other's code does functionally :laugh:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Agile is a lot about communication, but not just with the team, but with the business and stakeholders as well. I think the biggest lie of agile and scrum and everything is that "everybody should be able to do anything." At my last job they fired all Dynamics CRM people and told me "you do it because we're a scrum team." What the hell, I'm a developer! I never touched CRM in my lifetime and you just fired people who had years of training and experience! It's not only not possible to know everything, but in practice coder 1 will write modules A, B and C and coder 2 will write modules D, E and F. They could take over each other's code, but it'll be slow and painful. At least they'll know what the other's code does functionally :laugh:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
I think the biggest lie of agile and scrum and everything is that "everybody should be able to do anything."
The real skill in managin a team is to find everyone's strengths as well as weaknesses and delegate accordingly. Whatever you call the methodology you find what works.
They call me different but the truth is they're all the same! JaxCoder.com
-
An Introduction to Agile Modeling[^] If so (or if not and you peruse it) - I have a lot of pennies for your thoughts.
Latest Articles:
16 Days: A TypeScript application from concept to implementationI read the book version quite a while ago. From what I remember it was good (with the warning that I usually like Ambler's stuff). It seemed useful, without being rigid and dogmatic. Of course now is the time that you and others remind me that I'm an idiot ;P
TTFN - Kent
-
I read the book version quite a while ago. From what I remember it was good (with the warning that I usually like Ambler's stuff). It seemed useful, without being rigid and dogmatic. Of course now is the time that you and others remind me that I'm an idiot ;P
TTFN - Kent
I read some of his stuff a while back. He is generally SO flexible that things end up in places where they don't belong...tables, columns, heads, hands....etc... So no, *you* are not the idiot in this case....
-
An Introduction to Agile Modeling[^] If so (or if not and you peruse it) - I have a lot of pennies for your thoughts.
Latest Articles:
16 Days: A TypeScript application from concept to implementation -
-
An Introduction to Agile Modeling[^] If so (or if not and you peruse it) - I have a lot of pennies for your thoughts.
Latest Articles:
16 Days: A TypeScript application from concept to implementation1. The more you overtake the plumbing, the easier it is to stop up the drain. - Scotty 2. Corollary: The more you complicate process and design to compensate for a lack of expertise, the easier it is to screw up a software project.
-
An Introduction to Agile Modeling[^] If so (or if not and you peruse it) - I have a lot of pennies for your thoughts.
Latest Articles:
16 Days: A TypeScript application from concept to implementationMy treatise on agile, guaranteed to please some, irk others, and cause drowsiness in the rest. :) Simply put, I found it useful to revisit the Agile Manifesto, and describe the points made there in terms of actually accomplishing them in real-world America with efficiency, productivity, and quality. https://www.linkedin.com/pulse/agile-principles-from-traditional-american-view-jeff-jones/[^]
