|
Ross J. Pettit has over 15 years experience delivering complex development projects and managing multi-national operations as a developer, manager, and consultant. He holds a BS in Management Information Systems and an MBA. He is currently consulting to global clients implementing Agile practices as a Client Principal with ThoughtWorks.
Subscribe to this RSS Feed - 
|
|
Written by Ross Pettit
|
|
Tuesday, 08 April 2008 11:51 |
 In many IT organizations, Quality Assurance (QA) staff are not dedicated to projects, but are "shared resources" supporting many projects simultaneously. Vast armies of QA staff execute defined scripts to test and certify an application once development is complete. Because they lack application familiarity and test only at the end of the development lifecycle, QA staff require significant execution support, and the feedback they provide is late in coming and often inaccurate. By comparison, on Agile projects, QA staff are dedicated team members. Testers are 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. In the Agile approach, QA is less of an encumbrance and more a partner in delivery, increasing the efficiency of the software development process and the effectiveness of solutions produced.
|
|
|
Written by Ross Pettit
|
|
Saturday, 09 February 2008 08:19 |
 Performance
and quality metrics are not indigenous to traditional IT practices. When metrics are brought to bear to achieve
greater transparency or compliance in an IT project, they are imposed on teams,
grafted on top of day-to-day execution.
The poor alignment of metric to execution means project managers must
constantly translate work effort into progress measures. Because these acts of translation take a lot
of time and are not natural fits with execution, project management is often
opaque and inconsistent. By comparison, business-oriented
metrics are natural byproducts of the way work is performed in Agile
practices. Measures of progress, quality,
and functional completeness are extensions of day-to-day execution of Agile
practices. This means that instead of
chasing after management data, the Agile manager is able to concentrate his or
her efforts managing the people in a team to achieve the business goal.
|
|
Written by Ross Pettit
|
|
Saturday, 05 January 2008 07:33 |
 IT organizations face increasing pressure to reduce budgets, improve quality, and deliver more quickly. These business demands quickly come face-to-face with current IT practices: cumbersome requirements management, opaque project management, complex architectures, and lengthy testing cycles. Recognizing the need to be "more agile" in response to these pressures, IT teams are increasingly looking to Agile practices. Because they distill the essence of IT execution into a collection of efficient, waste-free activities, Agile practices offer an intuitively appealing way of working.
|
|
|
Written by Ross Pettit
|
|
Saturday, 08 December 2007 07:13 |
 Strategic or mission-critical application development requires developers to have more than just technical programming skills. They must also be fluent in the business context of the applications they develop, and have a working knowledge of the technical environment of the business. This makes global sourcing that much more difficult: whereas technical skills can be acquired in the classroom or from prior experience, complex business problems and esoteric technical environments are typically business-specific. As a result, they must be learned and mastered in a specific environment, and pose a challenge to global sourcing. The collaborative aspects of Agile practices - both among developers and with business partners - offer a solution to this problem. By effectively incubating high performing, globally sourced teams, Agile practices allow an organization to source IT application development not only for cost reduction, but for strategic solution development.
|
|
Written by Ross Pettit
|
|
Saturday, 10 November 2007 09:50 |
 Agile
practices such as unit testing, story-based requirements gathering, and pairing
are intuitively appealing ways to achieve higher quality and mitigate risk of
change. At first glance, they even seem
relatively easy to execute: how hard can it be for two people to collaborate,
write small business-oriented requirements, and code tests with each bit of
software? Executing Agile practices can
be quite difficult to perform. For one
thing, they make people uncomfortable because they challenge work habits long
established in IT. For another, they
give the appearance of reducing productivity.
This can lead teams to try to take shortcuts to becoming Agile. Selectively gaining experience with Agile
practices is of value when first taking them on, but denying them completely leaves
the benefits of Agile practices unrealized, and can cause more harm than good
to a development team.
|
|
|
|
|
<< Start < Prev 1 2 3 4 5 Next > End >>
|
|
Page 1 of 5 |
