Jan de Boer wrote:Doing your job right is a mindset. You do not have to put a label on it. If you generalize agile to values and mindset, then what is it? This good mindset, and good values exist without agile. They would have existed if no-one ever invented the word agile in the software context. It is like saying socialism is not a certain way to organize your economy, but a mindset of sharing, and the values of caring for each other. Sharing and caring exists without socialism. Replace socialism with agile.
In 'Learning Agile' (p164), Jenny and I wrote wrote:To understand if you’re ready for respect, ask if you, your team, and your boss are OK with:
• Trusting the team to do the right thing, and deliver each feature at the best possible date based on relative value and how the project progresses—even if it causes the project to take longer than you expect?
• Giving the team enough time to do the work, and not demanding overtime of them?
• Trusting the team to choose the tasks that are right for them and for the project, rather than relying on strict roles, RACI matrices, etc.?
• Not being able to ever say again that you don’t know why the team decided to do something the way they did?
Divya Shiv wrote:Is the Agile concepts in the book is explained based on the standard tools and processes or all other tools(Kanban/ Zenhub etc) and processes are covered ?
Tim Holloway wrote:I've seen - and been wearied - by situations where you have systems so complex that one or more components could be updated daily (if permitted, this would be one of them). But letting everything slide like this borders on criminal. These are people with large-computer IT backgrounds and they should know better. I'd say that they're just planning to ride until it blows, then bail, but the way they're set up at the moment looks like all that would do is get them sued from every direction at once.
Rahul Dayal Sharma wrote:The technical level user stories has multiple acceptance conditions which are then placed on the TODO lane of your kanban board
Jan de Boer wrote:
Tim Holloway wrote:I was doing "Agile" many, many years before the term was invented..
Tim .... Everybody was doing "Agile" before the term was invented. The term "Waterfall", and especially the "Agile" view of what "Waterfall" was, is also invented by "Agile". And THAT is the whole problem.
Jan de Boer wrote:This until finally two years ago I told my brother in law to slow down and let me take notes. Then I made the evil thing called documentation, you could even call it a manual. And to make it even worse…we printed it out on paper. Can you imagine? Paper? The thought alone. We now print out the manual every time we visit and our problem is solved. But, helas, we are so totally not agile. Preferring documents over human contact, we must be autistic!
Jan de Boer wrote:That is agile, write nothing down, be interrupted constantly, and you can say everything because we are a team and we do retrospective, but if you complain about agile, you are a bad programmer.
nick woodward wrote:I'm currently learning to develop software and was wondering if this book is good from that perspective rather than from a managerial role? Also what methodologies does it cover? O'Reillys shop doesn't seem to cover either of these. Apologies if these are ill informed questions, I've just started looking into the area and the headfirst books are always a good place to start.
Pete Letkeman wrote:I would also like to know the answer to this as I’ve been a (pretty much the single) developer for a one stop shop.
Does this book give the developer like me a place to start with Agile development?
Kent Beck, author of Extreme Programming Explained (Beck 2000), described the use of Extreme Programming (XP) using similar levels. Asked about XP and the five levels of the Software Engineering Institute’s “Capability Maturity Model,” he replied with XP’s three levels of maturity:
1. Do everything as written.
2. After having done that, experiment with variations in the rules.
3. Eventually, don’t care if you are doing XP or not.
As a developer, my view of agile software development is skewed mostly towards the technical practices like pair programming, test-driven development, refactoring, and continuous integration. Kent Beck, Jeffries, Fowler, Martin, and others like them had a more developer-oriented focus: they wanted to make developers' lives better and work more enjoyable. Software quality and simplicity was definitely something that was highly valued and there was strong focus on technical excellence.
I'm not condemning the book in any way, I'm just giving my honest impressions. The book looks like it covers a wide range of topics from principles, Scrum, XP, Kanban, Lean, etc.