Ask HN: Is Agile wrong for my team
7 comments
"Agile" isn't a methodology, it's a set of value statements about princples. See:
http://agilemanifesto.org/
In particular, Agile is a statement that you value:
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
I'd be willing to bet that a 2-person team that's moving fast, exceeding expectations and building necessary stuff well is already doing all of the above.
I suggest getting your boss to read that manifesto, then sit down as a team with him / her, and work through the principles. Discuss each one, and identify areas for improvement. If your boss is dead-set on a particular methodology, you might do well to highlight the first point above :)
http://agilemanifesto.org/
In particular, Agile is a statement that you value:
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
I'd be willing to bet that a 2-person team that's moving fast, exceeding expectations and building necessary stuff well is already doing all of the above.
I suggest getting your boss to read that manifesto, then sit down as a team with him / her, and work through the principles. Discuss each one, and identify areas for improvement. If your boss is dead-set on a particular methodology, you might do well to highlight the first point above :)
I agree. Sounds like the team is already Agile. If the boss wants to be agile too, that's great! Management buy-in is very important for Agile to work. They need to understand and accept that the dev team is ultimately in control of the way they work, and the business side needs to provide the things the dev team needs to do their work.
From my experience sys admin work is hard to manage using scrum. I have used kanban or a combination of kanban and agile to track my work.
The training I attended said the ideal team size for scrum is 4 - 7 team members. I would say follow whatever makes you feel comfortable, as long as you deliver some value to your end users it is all good.
Having said that at my current work I am using a trello board to manage all my stories and find it helpful even though it is just two of us at the moment. If you have any more questions feel free
I am going to shamelessly promote my startup, check out http://askmeanything.me/ , to ask questions to founding engineers.
The training I attended said the ideal team size for scrum is 4 - 7 team members. I would say follow whatever makes you feel comfortable, as long as you deliver some value to your end users it is all good.
Having said that at my current work I am using a trello board to manage all my stories and find it helpful even though it is just two of us at the moment. If you have any more questions feel free
I am going to shamelessly promote my startup, check out http://askmeanything.me/ , to ask questions to founding engineers.
Likely, yes.
If you already doing efficient work, you don't need someone to join your team and to justify his existence to inflict methodology over your already working workflow.
Methodologies makes sense to organize large teams with diverse backgrounds and experiences.
Small, efficient, and already professional teams usually neither need babysitting nor organizing methodologies to do it's work.
If you already doing efficient work, you don't need someone to join your team and to justify his existence to inflict methodology over your already working workflow.
Methodologies makes sense to organize large teams with diverse backgrounds and experiences.
Small, efficient, and already professional teams usually neither need babysitting nor organizing methodologies to do it's work.
Agile is not a methodology, it is a set of values. When you write:
"Small, efficient, and already professional teams usually neither need babysitting nor organizing methodologies to do it's work."
... you're right, most likely because that team is already Agile.
"Small, efficient, and already professional teams usually neither need babysitting nor organizing methodologies to do it's work."
... you're right, most likely because that team is already Agile.
If it's ain't broke, don't scrum it.
OK, I have one for ya:
Scrum - Cialas(TM) for a manager's CV[1].
1 - Don't take Scrum if you are responsible for delivering a product. To avoid long term WTF, seek another job if your stand ups last more than 4 hours. Scrum does not prevent the spread of defects. If you have any sudden decrease in productivity, stop taking Scrum and call your developers immediately.
Why tell your development team you are incorporating Scrum? Because, sooner or later, when the moment is right, you can spring it on them and get the keyword on your CV.
Scrum - Cialas(TM) for a manager's CV[1].
1 - Don't take Scrum if you are responsible for delivering a product. To avoid long term WTF, seek another job if your stand ups last more than 4 hours. Scrum does not prevent the spread of defects. If you have any sudden decrease in productivity, stop taking Scrum and call your developers immediately.
Why tell your development team you are incorporating Scrum? Because, sooner or later, when the moment is right, you can spring it on them and get the keyword on your CV.
Well played! :-)
This is worth reading: http://algeri-wong.com/yishan/engineering-management-process...
> We exceed expectations, do we need Agile? We are organized and documented.
I would ask your boss this question.
I would ask your boss this question.
Just give it a try for a week and see if you find value in the methodology.
Firstly, a week is nowhere near long enough to evaluate a methodology.
Secondly, there are many Agile methodologies. The first step should be to sit down as a team and work through the manifesto, identifying areas for improvement.
Only once that's done is there any point in thinking about choosing a methodology.
Secondly, there are many Agile methodologies. The first step should be to sit down as a team and work through the manifesto, identifying areas for improvement.
Only once that's done is there any point in thinking about choosing a methodology.
Let's not get all jumpy on the downvotes from a difference of opinion; a week may not work for you but for others... well we move fast.
The point was to encourage our fellow HN member to be open minded and try it for a short period of time. From there he can determine if the change has begun to yield any value or not.
The point was to encourage our fellow HN member to be open minded and try it for a short period of time. From there he can determine if the change has begun to yield any value or not.
And that advice is simply wrong. It's simply not possible for any team to reasonably assess the pros and cons of a given software development methodology - with the possible exception of the one they're already using - in a week.
Suggesting a team 'try a methodology for a week' is inviting a train-wreck.
Suggesting a team 'try a methodology for a week' is inviting a train-wreck.
Good to know you're the benchmark for productivity in the industry.
My own experience - across multiple teams, multiple organisations, multiple languages and frameworks - is that it can take weeks to evaluate even relatively slight changes to existing methodologies.
Let's say the OP decides to adopt Extreme Programming.
How long would you say that a team with zero experience in that methodology would take to get to the point where they're practising it well enough to perform a useful evaluation of the consequences?
Let's say the OP decides to adopt Extreme Programming.
How long would you say that a team with zero experience in that methodology would take to get to the point where they're practising it well enough to perform a useful evaluation of the consequences?
Less time than it would take for you to realize that our experiences form only our perceptions, not universal law.
We exceed expectations, do we need Agile? We are organized and documented.
Can it be a hindrance to our workflow? Forgot to mention there is a lot of legacy code, and tons of bug fixes, its pretty dynamic.