Tag: applications

Globally Distributed Development

Welcome to the second issue of the Agile Journal. This month, we explore the many challenges Agile teams face in running globally distributed development projects.

Globally distributed development can include all/any of the following:

• Teams with developers, testers, users and/or other team members working at more than one location.
• Teams engaging with third-party partners -consultants, vendors, even customers - to deliver business applications.
• Teams that must incorporate a number of different styles (cultural, technical, management, etc.) across their distributed locations.

---

Intellectual Property Management Issues for Development

To maximize intellectual property (IP) value and mitigate risk while operating in an open source application development environment, enterprises need to understand the distinction between real and perceived risks and values by utilizing processes, governance and tools. This is particularly important when involving an outsourcing partner. A lack of intellectual property capture and protection makes it harder for the outsourcing company to move from one outsource vendor to another.  As a software development "value chain" evolves over time, with changes in the business and technology environments, the value of leveraging open source software may grow or decrease in value. So it makes sense to understand and review open source arrangements.  In this scenario, if the intellectual properties associated with managing and producing the product are no longer available, significant flexibility will be lost. 

---

CASE STUDY: VA Software
Agile development methodologies aren't one-size-fits-all. Independent software vendors (ISVs) have unique needs-external customers, aggressive release dates and competitive pressures-that require tailoring software development methodologies that work well in corporate IT settings. Faced with a major new project and bogged down by a big design up-front process, VA Software adapted Extreme Programming (XP) to help build the latest versions of SourceForge® Enterprise Edition (SFEE).

---

Open Source Tools for the Agile Developer
A defining characteristic of agile development is to keep moving forward, recognizing working code as the primary measure of valued software. Undoubtedly, there is no way to judge a software system until you have a system to judge. Yet, experienced developers recognize that requirements frequently change and traditional methods have achieved very little success in stabilizing requirements early in the lifecycle. Instinctively, we may feel change impedes progress, but agile developers embrace an attitude where change is viewed as an opportunity to improve the system. A variety of open source software tools  can enable important agile practices, allowing you to keep moving forward so long as you are willing to embrace change.

---

The Economic Impact of Open Source
For many years, pundits have anticipated seismic change from open source. Beyond the high-profile changes, the effects of open source can be seen everywhere in software development today. While still an emergent phenomenon, there are cost, revenue and intangible benefits for any company that becomes an active consumer and contributor to the open source community now. 

---

Stretched to the Limit

If the "World is Flat" how come we still have bumps in the road of collaboration and communication?

When serendipity taps you on the shoulder I've found it best not to ignore the intrusion. I recently got back from an intense trip to India, speaking at several seminars and to a number of our leading customers. On my return I picked up "The World is Flat" by Thomas Friedman and this book provided me with a deeper perspective on what I had just learned, face-to-face, with the same groups of people I had just met in Hyderabad, Bangalore and Delhi. And here we are in the second edition of Agile Journal talking about Offshore Agile Development.

---

An Agile Approach To Managing Distributed Development
Traditional approaches to distributed development impair flexibility: they don't expose what's actually happening on the ground in different locations, they lack common and effective communication channels, and they substitute "hope" for "managed process" when reconciling work. Distributed development should be as responsive to change as co-located teams.  A program managing distributed development requires behaviors that engender agility.  Three contributing factors are release cadence, transparency of activity, and lightweight communications.

---

Generating Real Value From Your Service Oriented Architecture

The question is no longer how best to automate business systems, but rather how to improve what's already been automated. We are nearly finished with the initial wave of IT adoption and most of what can be automated already has been. This means that the essential set of features and functions required to run a business already exists in some form. The trick is how to reuse and repurpose existing investments for additional value.

---

Make SOA Governance A High Priority

Today's enterprises face growing regulatory pressures with legislation such as the Sarbanes-Oxley Act, the Gramm-Leach-Bliley Act, HIPAA, the Patriot Act and others. As a result, corporate and IT governance - the processes, controls and reporting infrastructure over business and IT activities, respectively - are becoming progressively more pervasive as a means for providing the compliance infrastructure necessary to satisfy this list of complex regulations. Combine this increased pressure for corporate traceability and visibility with the "next big thing" in software, service-oriented architecture (SOA), and you have a challenging governance environment to say the least. SOA's loosely-coupled nature forces IT away from monolithic application development and deployment, and as a result it greatly increases the number of moving parts that must be managed and governed.

---

Turning the Fragile into the Agile

Tool integrations are notoriously fragile; how can we fix this problem once and for all?

The first sign of trouble is the unusually long time it takes for your IDE to start one morning. Maybe you can't access the trouble tickets any more or the team members cannot build their applications or run the automated test suite.

---