One point I mention in my book is that projects often call themselves "agile" but are everything but agile. In agile projects the whole team has respect to its members, and communicates in an advisable form -- no bubble! "Agile" is not a "product" to sell, agile is a basic attitude. All people do want to archieve the best for the projects, ask if something isn't clear, anti-patterns like a collected in my Wikipedia article, are seldom. Selfish behaviour is a no-no as well as people who always got to be in the limelight. If you do want to learn more about the best approach for agile teams, when a so called "agile team" is not an agile team and if you want to read about the concrete advantages of agile processes ... please read my book. It is also of value if you want to learn about the infrastructure, the tools to use in order to support an agile process. Although agile projects do focus on basic values also tools are very, very important in order to accomplish the daily tasks (like Test-Driven Development, Continous Integration, testing of components, functional testing of Java Swing applications, functional testing of web applications, Software-Configuration Management, Standards and a lot more ...).
8 comments:
Good inputs. Is there an english version of your book?
currently no. You may point this out directly to the publisher. Ask O'Reilly for a translation and the chance increases ... :-)
Will try that out. I am currently working to facilitate non-agile projects to move towards a faster route...and using 'agile' as one of the tools to achieve the objective. And in such situations, the most common situation is the mindset of people who always want to fall back and compare agile approaches to their existing traditional/non-agile approach....so its both fun and a big challenge...anyways, thanks for your inputs....
you will most probably benefit from agile methods, your developers, customers will see the concrete advantages ... you may use dedicated strategies to introduce agile processes and support the stakeholders while learning.
Yes, am doing what you are saying...but given the constraints of budget and rock-solid traditional thoughts, to bring a change is a huge task. What has seen success is a slow transition by inducing some of the elements in the project. Mainly the daily stand-ups and iteration backlog are the most successful elements. also, the burn-down chart is a solid eye opener.
yes, it can be a huge task. You are right that a slow transition is a good strategy, but sometimes being too slow does not work as well. Every project is different -- I totally agree as well that stand-ups, burndown-charts and iterations (backlogs) are also good first steps. I would also add opening the mind for respect, open and proactive communication is essential. You can also start develop unit tests for your classes to introduce agile development "in the small". But: what you do, do it right ... I have seen many semi-agile projects that do such stuff like stand-up meetings but doing more errors there than good things.
Loved reeading this thank you
Post a Comment