Recent Articles
Article by TechWell Contributor |
Jan 5 2008 - 10:00pm Recently there has been a lot of talk on whether we need an Architect on agile teams or not. There have been never-ending discussions on various forums both inside organizations and out in the public questioning the value that an architect can bring to the agile project where the architecture evolves with every iteration. This has led many traditional Architects to scramble for cover and opened gates for a new breed of architect, the Agile Architect. The traditional ivory tower Architects are gradually proving to be the weakest link in the chain for agile projects. The bulk of the traditional Architect's responsibilities are now split amongst the agile team, thus leaving them without a lot of work that they were previously doing. The Agile Architects are emerging in line with Charles Darwin's theory of "survival of the fittest." The role of an Agile Architect on the team is unquestionable and many agile teams vouch for the fact that he is one of the most valuable members of any agile software development team. Read More
Article by TechWell Contributor |
Jan 4 2008 - 10:00pm There are many ways to transition to an agile process. Choosing the approach that is most likely to work best for your organization can be critical to a smooth transition. Through helping hundreds of teams make the transition to agile over the years, I have identified six core patterns that teams use to initiate the transition to agile. These patterns fall into three sets of opposing pairs. You should choose the core pattern from each set that best suits your team or organization:Start Small or go All In?Technical Practices First or Iterative First?Stealth Mode or a Public Display of Agility? Read More
Article by Guy Beaver |
Jan 4 2008 - 10:00pm Defect reduction through early and detailed requirements specification is a common outcome of process improvement efforts in product development. Enterprise requirements management becomes a specialization that requires expert business systems analysts to gather and document specifications that are detailed, accurate, and complete. If we apply Lean principles to the requirements gathering effort we see a backed up queue. Working to "Eliminate Waste" is a fundamental premise of Lean thinking in Software Development. Mary and Tom Poppendieck consider this so fundamental that they make it principal number 1 of 7 in their Principles of Lean Software Development.[i] They dispel the myth that "early specification reduces waste." In fact, for software development, early specification is waste. This article extends this myth-busting by exposing what can happen when process improvement techniques are blindly applied to requirements gathering. The suggested solution is to replace early detailed specification with solution roadmaps that can be detailed by collaborative teams at just the right time. Agile methods provide the structure and mechanics to allow business vision to lead product development with cross-functional teams that unfold detailed requirements when needed. Read More
Article by Jeff Patton |
Comments (2) |
Dec 14 2007 - 9:41am In this week's column, Jeff Patton sends a reminder that software developers who neglect the practice of iteration will get caught either delivering poor quality software or delaying schedules in order to make time to iterate. We kick ourselves, or others, for not "getting [software] right up front" when we all know that the hardest part of software development is figuring out what to build. But there's hope, and it comes in the form of prototypes and frequent iterations. Read More
Article by TechWell Contributor |
Dec 7 2007 - 10:00pm Over the course of the past decade, Agile software development has progressed from a grassroots, almost underground movement, to the mainstream. Early successes have paved the way for broader acceptance of Agile principles and practices, facilitating dialogue not only in IT back offices, but corporate boardrooms as well. With an ever-increasing focus on profitability, time-to-market, and customer satisfaction, the vigorous debate over Agile adoption appears to be shifting from a question of "why?" to one of "how?" To maintain momentum, the Agile community must shift its focus from "spreading the gospel" to architecting effective real-world adoption strategies. Addressing institutional adoption issues requires a less rhetorical approach which recognizes that Agile methods and Agile leaders must themselves embrace change and seek compatibility if Agile methods are to find a persistent role in modern business vernacular, whether specifically in the context of enterprise software development or in settings further afield. Read More
Article by David Webb |
Dec 7 2007 - 10:00pm Stickingpush pins into a wall map to denote Agile team member locations doesn'ttranslate into a productive, global development organization. Seeking outcompanies that have created efficient, disbursed teams and asking how they didit won't help you either. There are no best practices, just a few good ideas tothink about and tailor around your particular objectives. Truly connectingthose push pins means taking a critical look at three universal issues everyorganization must grapple with to make a global Agile team successful: data considerations,communications needs, and a company's Agile readiness. How you handle each ofthese issues will vary widely, and there are no best practices that can help. Read More
Article by Scott Ambler, TechWell Contributor |
Dec 7 2007 - 10:00pm Geographically Distributed Development (GDD) is a common strategy in the software world today. Organizations are gaining experience in developing software globally and are discovering that the competitive demand for best-in-class, high quality applications requires greater agility in quality management. Unfortunately, IT budgets are not keeping up with the staff required for quality management and the response is to accelerate quality management by leveraging global teams. This article compares and contrasts agile GDD testing strategies for affecting quality management. Read More
Article by TechWell Contributor |
Dec 7 2007 - 10:00pm Refactoring is one of the cornerstones of the technical agile development practices. It is the mechanism that allows the design and architecture of a system to evolve over time. It is one third of the red-green-refactor loop and the core of test driven development (TDD). But does it really deliver on its promises? If you and your team are diligent writing tests and refactor mercilessly will your software evolve well and easily? Is the cost of refactoring always small and affordable? Refactoring is not a silver bullet, and sometimes is painful and expensive, so we cannot rely on always refactoring with a limited cost. However, any design, no matter how appropriate today, will be inappropriate tomorrow as the requirements change, and refactoring is our best tool to evolve our designs and architectures. Read More
Article by TechWell Contributor |
Nov 9 2007 - 10:00pm Agile teams struggle with successfully applying Agile approaches to project planning and delivery. In particular, an area that needs to be explored is negotiating customer commitments within an Agile process. Common to Agile processes is delivering customer value in short cycles and small increments. Customer commitments are made for each increment and meeting these small commitments early in the project will build the trust that is crucial in order for Agile to be successful. In this article, I will explain the key steps, and practices within each step, that will assist in making and delivering on customer commitments in an Agile fashion. Read More
Article by Charles Suscheck, TechWell Contributor |
Nov 9 2007 - 10:00pm During the past few years there has been a trend developing in the software industry toward agile development processes. Unfortunately for the business analyst (BA), much of the literature regarding agile development focuses on the perspective of the developer, largely ignoring the role of the business analyst. BAs play a key role capturing requirements on large, software-intensive projects. Yet agile methodology emphasizes face-to-face communication over written documentation. Teams are co-located where programmers and their "customers" interact directly as a means of eliciting requirements. Organizations that are moving toward agile development may wonder if a has a role in agile software development. The answer, as addressed by this paper, is a resounding "Yes." Read More
