The continued rise of the business analysis profession has led to a surge in software tools specifically designed for the business analyst. Find out what types of tools are in the marketplace today and how to select the right business analysis software tool for your organization.
What can happen over a game of golf? You learn what you don't know, you learn more about what you do know, and you learn to listen to what others know. See how two managers and a caddy team up for some valuable lessons about staying out of the rough.
Jean Tabaka believes in the power of an entire agile organization. These ten characteristics of an agile organization may seem counter to market success, but she explores why they are wholly embedded in twenty-first century business success.
Pair programming is an Agile practice that has been shown to greatly improve code quality without a huge increase in development time. This article explains the ins and outs of pair programming and some things you need to consider before you tell team members to grab a partner and get programming.
Whether you're working on a collocated or a distributed team, it's important to take stakeholder requirements into account: "Who" are they and "where" are they located? In this article, Mary Gorman offers some tips to help you narrow the gap between thinking and acting globally and locally.
Allowing an individual to hold a project hostage to his knowledge and expertise is bad for the project and for the team. Fiona Charles describes one captive project and shows how it could have been remedied.
How do you adapt inspections to a twenty-first century distributed workforce? A key part of the inspection process is the team meeting, which provides peer pressure to participate and consensus on defects. Teams working in multiple time zones have limited opportunities for the team meeting. A list of requirements and the functions needed to solve this problem based on real-world experiences should help anyone faced with this problem.
Developing an accurate prediction process is complex, time consuming, and difficult. But, basing predictions on causality rather than correlation and learning how to "predict the past" can help us gain confidence in the validity of our work.
Burn-down charts have become a popular project artifact, but too often, people accept the default chart from whatever project management tool they're using. What choices can we make about the chart format and scale that will help us create charts that answer the questions that are really important to us? And when the chart looks "funny," what could it possible mean?