Technological debt is mistakenly thought of as a technical problem, but when system design cannot change according to the needs of the business, it becomes a business problem. Big Design Up-Front leads to technological debt. Architecture must be allowed to emerge according to the needs of the product and the business. We know iterative, emergent development works; iterative, emergent design is no different. Agile teams should use Retrospectives as a tool to determine current needs and enable emergent design.
Within the Agile community retrospectives are widely seen as the mechanism for promoting learning and change. But many teams fail to hold retrospectives, or fail to act on the findings, thus they fail to learn and improve. If we are going to fix this we need to change our approach to retrospectives, and find new ways to learn and create change.
In this article, Scott Ambler makes a strong case for the need for architectural envisioning and modeling on agile projects. By taking the time up front to create a solid architecture, your team can reap benefits like improved communication, increased productivity, and even reduced development time.
In this article we describe our work with teams that were spread between the US and India, and with the unavoidable cultural difference. We used a facilitated retrospective to discover the most challenging issues in the process and, just as important, to build a team and increase trust between team members. In later work with the teams, we noticed the immediate positive impacts on the people and the process.
At the core of all software solutions are underlying software architectures. The architectures reflect initial assumptions about how products fit together, which features are of value to customers, what are the expected integration points, with which related technologies. As software products find acceptance among customers, and technologies continue to evolve, the creators (vendors) of these solutions eventually find the need to adapt underlying architectures. Agile provides a means of doing this early in the product lifecycle and with continual review that provides the creator with the ability to adapt quickly and effectively to changes is the marketplace.
This paper can help you in deciding how to leverage test automation, especially in data warehouse projects.
Statistical Process Control (SPC)-is it appropriate for a software development organization? If you're asking yourself this question, you're not alone. The application of SPC has a great track record in the arena of physical product manufacturing, but are these concepts as portable to engineering and digital product manufacturing processes as much published literature, and many consultants, would have us believe? This presentation will discuss a profound realization made during the road to CMMI (Capability Maturity Model Integrated) maturity level 5 which was attained in October, 2005 at Lockheed Martin Integrated Systems and Solutions (IS&S). The presentation will also provide guidance on how to determine whether SPC is appropriate for a given process or not.
Many managers claim to have an open-door policy. They want to be available to their employees. But do they really have an open-door policy, or is it a handy name for a commendable intention? Naomi Karten describes the flaws in open-door policies and offers suggestions for making them work.
Negotiation skills are useful in life and essential for professional success. This week, Payson Hall provides a short tutorial on project negotiations that includes a technique to help you look for solutions. The use of motivation and the "Iron Triangle" is a good starting point.
In certain company, the topic of favorite programming languages can elicit the same response as other taboo subjects, such as religion and politics. But, Chuck's going out on a limb to discuss his new favorite language, D, and some of its best features, such as its being strongly typed and compiling to native code, yet it is garbage collected.