Home
The Agile Manager 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
|
|
Thursday, 04 January 2007 |
In an effort to justify IT investments, we have increasingly looked to quantify the "business value" of projects. While there is merit in doing this, in practice it can generate more heat than light. There is a limit to the accuracy with which we can predict the future, how much data we can collect, and the extent to which business decisions can be expressed as mathematical formulas. The result is that "business value" is neither ubiquitous language for IT projects nor an absolute measure of IT effectiveness. Still, there is value in business value: properly applied, it provides guidance for project decisions and is another mechanism through which IT aligns with business objectives.
Tags:
Click to add your tags...,
|
|
|
Written by Ross Pettit
|
|
Thursday, 07 December 2006 |
|
The demand for IT governance is increasing at a rate faster than the capability to govern IT is maturing. While greater scrutiny on spending and increased business regulation ratchets up pressure, IT management struggles even to come to consensus on a definition of what governance is and is not. Governance initiatives are typically little more than bureaucratic "bolt-ons" to monitor employee activity. The results speak for themselves: although it consistently appears as a top-10 priority for CIOs, only about 10 percent of CIOs report "very effective" governance, and nearly 60 percent report neutral or outright ineffective governance practices.[1] To make governance effective, there must be a simple yet complete definition of governance that is results-oriented, inclusive of all IT activities, and non-burdensome to execute.
Tags:
test,
Click to add your tags...,
|
|
|
Written by Ross Pettit
|
|
Thursday, 09 November 2006 |
The overwhelming success of initial Agile projects - simultaneously achieving a high degree of collaboration, technical quality, and operational transparency - quickly leads stakeholders to look for ways to roll-out Agile practices across the organization. Unfortunately, the consultant coaching or "trial and error" models common to initial Agile projects do not scale beyond small teams. For one thing, it is difficult to leverage individual "practice leaders" across multiple teams, geographies, and projects. For another, simply rolling out better development practices doesn't improve organizational responsiveness. To successfully undertake a large-scale "program of change" an organization must look for ways to leverage skills and experience, monitor practice adoption, align staff recruiting, and measure results.
Tags:
Click to add your tags...,
|
|
|
Written by Ross Pettit
|
|
Thursday, 05 October 2006 |
|
Taking an Agile approach to software development for the first time is no small task: there are a number of different practices to onboard and process change is disruptive, frustrating and potentially demoralizing. How do you onboard Agile practices and still meet delivery requirements? To what extent can these be introduced, especially the first time around, so that they stick?
There are two things to balance when introducing new practices: adopt at a pace that doesn't push too far too fast and simultaneously establish a "critical mass" of core practices to reap symbiotic benefits. While there are no hard-and-fast rules on how or where to begin, the right sequence can increase probability of success and set the stage for greater process adoption.
|
|
|
Written by Ross Pettit
|
|
Tuesday, 01 August 2006 |
The responsiveness of Agile teams results from disciplined execution of best practices. When executed consistently, these practices - particularly automated testing, continuous integration and iterative delivery - create integrity of completion for every unit of work delivered. There are specific tools that reduce onboarding time and automate these practices, making them becoming part of every day activity. However, the tools offer no shortcut to Agile adaptation: while the tools make the practices more efficient, they do not themselves provide value without fundamental practices in place.
Tags:
Click to add your tags...,
|
|
|
Written by Ross Pettit
|
|
Thursday, 06 July 2006 |
Service Oriented Architecture (SOA) defines a state of application development that is both the fulfillment and re-enforcer of agile values. Core Agile practices, notably business-oriented requirements, frequent delivery and testing, engender a portfolio of valuable services, while SOA reinforces agile values of reduced waste and build integrity by creating a pervasive platform for valuable, re-usable functionality. Implemented in an agile manner, SOA rapidly enables greater responsiveness to changes in the business environment.
Tags:
Click to add your tags...,
|
|
|
Written by Ross Pettit
|
|
Wednesday, 07 June 2006 |
Becoming an agile IT organization is a process of continuous improvement and evolution in a number of different areas such as requirements gathering, project management, and development. This can be fulfilled in many different ways, with process changes enabling or inhibiting responsiveness to greater or lesser degrees. Ordering the different ways to evolve by degree of agile affinity defines a lightweight "maturity model" that allows an organization to asses current state, set targets, plot a course for continuous improvement, and build and measure against a business case for adopting Agile practices.
Tags:
Click to add your tags...,
|
|
| | << Start < Prev 1 2 Next > End >>
| | Results 12 - 21 of 21 |
|
