The Latest
|
When to Step Up, When to Step Back[magazine] Leaders can stifle progress when they unnecessarily interfere with team processes. However, as a leader, you don't want your project to go over the cliff and fail miserably or deliver the wrong results either. There are times when leaders should stand back and let the team work things out for themselves—and other times when leaders should step up and really lead. |
Pollyanna Pixton
May 1, 2008 |
|
 |
The Accidental Complexity of Logic[magazine] Much code complexity and no small number of program defects can be traced back to confusion over logical expressions and the expression of logic. Find out how you can get that complexity under control. |
|
|
What's the Deal with Investigators?[magazine] "Investigators aren't sure" is a phrase that frequently pops up in the media. Information systems workers seem to share this uncertainty. So, what's the secret to success in this "aren't sure" world? |
||
|
Let's Talk Agile[magazine] Agile development employs more oral communication, feedback, and interaction than traditional development. These communication tools can help ease the transition into the more interactive agile team relationship. |
||
|
The Chivalrous Team Member[magazine] Using the ten virtues described in Brian Price's modern code of chivalry, Martin and Mike illustrate the similarities between the best performing software team members of today and the Knights of the Round Table. |
||
 |
It's a Bug![magazine] Bug triage, like labor and delivery triage, is about deciding a course of action on the spot, often with minimal information guiding decision making. Discover what other lessons Robert has learned from Anne's experience in nursing that have practical applications in his hunt for bugs. |
|
|
Out of the Rut[magazine] Are you bored? Do feel as if all you do is repeat heavily scripted tests and as a result you aren't learning, discovering new problems, or finding bugs? These nine heuristics can help you get out of your rut and take back control of your testing process. |
||
 |
Communicate, Don't Assimilate[magazine] Opening an offshore office can be a tricky situation. Learn how to spread corporate values and processes to your new team members by working together instead of forcing them to adopt your way of thinking. |
|
|
Agile Adoption Patterns[article] The Done State practice is a definition that a team agrees upon to nonambiguously describe what must take place for a requirement to be considered complete. The done state is the goal of every requirement in an iteration. It is as close as possible to deploying software as a team can come. |
||
|
Quality Assurance: Value Added Partner, Not Blunt Instrument[article] In many IT organizations, QA staff execute defined scripts to test an application once development is complete. By comparison, on Agile projects, QA staff are dedicated team members. co-located with business and development staff. Because they collaborate with the development team on formulating acceptance criteria and engage in testing continuously through development, QA feedback is timely and relevant. |
||
|
Software Architecture Challenges and Significance in an Agile World[article] 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. |
||
|
Emergent Design: Leveraging Agile Retrospectives to Evolve Your Architecture[article] 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. |
||
|
The Trouble With Retrospectives[article] 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. |
||
|
Architectural Envisioning on Agile Projects[article] One of the common misperceptions with agile software development is that agilists don't "do architecture." This completely ignores the 11th principle of the Agile Manifesto which states that the best architectures evolve over time. In this article Scott Ambler overviews an agile practice called "architecture envisioning" which enables you to gain the value from modeling without the cost of needless documentation. |
||
|
Retrospectives: A Case Study on Techniques for Incremental Improvement[article] 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. |
Pages
AgileConnection is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.