Posts Tagged ‘agile software development’

Best Practices for Agile Software Development Defined

August 23rd, 2010 by damonpoole

In the last post I defined two Agile software development best practices I believe provide value to a wide variety of development teams.   Here I define three more practices that I believe are also important when transitioning to Agile Software Development; collocation, unit testing, and refactoring.

Best Practice for Agile Software Development: Collocation

Collocation is simply having everybody on a cross functional team in close proximity to each other. This compounds the coordination benefit of cross functional teams. This is orthogonal to outsourcing. Whether you are outsourcing or not, collocation only refers to whether a particular cross functional team is sitting near each other.

Best Practice for Agile Software Development: Unit Testing

Unit tests are simply tests that exercise small amounts of isolated functionality. That is, if you have a function that adds two numbers, instead of depending on running a user function that eventually calls the function, exercise the function directly. This often requires the use of mock objects that pretend to be things that the function needs in order to test the function in isolation from other functions that it depends on.

The cost of unit tests is in writing the tests themselves and refactoring code as new functionality is introduced to keep the unit tests testing at the right level. The benefit is that you can easily test changes quickly to find simple problems before doing more thorough and slower testing. It also provides a good safety net for refactoring, gets developers more involved in testing, and usually improves the design of the software.

Best Practice for Agile Software Development: Refactoring

Refactoring is the practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. That makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code. Any change has the potential to reduce the maturity and stability of the product, especially if you don’t have adequate testing in place. That’s why refactoring is usually paired up with unit testing and together these are frequently combined with continuous integration.

Continuous Integration: What’s Not to Love?

July 29th, 2010 by clucca

It seems like everyone loves continuous integration.  I’ll come out and say it- I love continuous integration! When we talk about the most widely adopted Agile practices, this one comes up the most.  Its positive benefits as a feedback mechanism provide a quantum leap forward in how development organizations think about their code.  I find it very difficult to see any downside in doing continuous integration, seriously what’s not to love?

Modern day continuous integration servers have 3 functions: Detect if a new build is needed, execute build, and notify people of the results. This is a great way of facilitating feedback to developers and allowing them to adapt and resolve problems.

But there’s something lurking in the shadows that nobody is talking about, maybe because people aren’t even aware that it’s a problem. Maybe it’s because we don’t want to ruin our love affair with CI and we’re all in denial.

What happens when those builds are done? What about the rest of “it”?

When I say “it” what I really mean is:

Most development environments include such things as complex application servers, automatic testing, release processes, compliance, audits, databases, 3rd party libraries, build dependencies, code analysis, unit tests… and another 1,000 other things I don’t have enough space to list here. How can you deal with this? Getting feedback to my dev team is a great targeted way to let people know code is broken, but isn’t this feedback useless if you can’t get the product out the door?

If I take an example build lifecycle of an application which is:

1.)    Build Application

2.)    Test

3.)    Deploy to environments (DB) (APP SERVER) <- by hand

4.)    Test

5.)    Redeploy (DB) (APP SERVER) (PROD) <-by hand

This may seem like easy in this example, but if we took all of these steps in the real world, this could represent hundreds of servers.  And this process will have to be repeated for every version of the product.

The crux of this issue is that if any of these steps are not performed 100% correctly, it translates to real dollar$ lost for the organization. These operations have to perform like clockwork.

Taking Continuous Integration to the Next Level

This is why I believe bringing continuous integration to the next level starts with the concept that the build produced from the CI server is just the beginning. Setting up a simple CI server and producing a build is easy, but managing it through the rest of its life is the real trick.

In a real example of this, we could take

1.)    Build

2.)    Run automated tests

  • If test succeeds: Deploy to to environments (DB) (APP SERVER)
  • If test fails: Notify dev team

3.)    Manual Testing in QA environment

4.)    Approval process

5.)    Redeploy (DB) (APP SERVER) (PROD)

Using AgileCycle RM

In this scenario I’m taking a version of the results from a CI build, run automated tests on them, monitor the test output and wait for success or failure. If there is success then deploy all components of the application, this includes a database components and a java war component. The build will then sit in QA for manual testing until its marked approved by the QA team, managers and operations team for deployment to production.

The idea here is if we automate these processes and decisions based on build, automated tests and approval process, you can produce code quickly and at a more rapid pace. If you can produce a clockwork-like automation around your build/test/deploy related processes, your team can spend time on what’s most important: Getting code out the door.

Benefits of Agile Development for Your Enterprise

April 13th, 2010 by AccuRev

Due to the promise of large gains in quality, productivity, and market responsiveness, Agile software development has been making its way into the enterprise in recent years, but there have been plenty of bumps along the way.  Any change to the enterprise has hurdles to overcome, and successfully adopting Agile development requires change within the organization than we have seen in the development process over the past several decades.  For instance, as you transitioned from C++ to Java or .Net, did you find it necessary to make substantial changes to your org chart?  Most changes in the software development process have been either the result of technology changes, such as moving from C++ to Java or pure html to AJAX, or changes in architectural patterns such as the introduction of object-oriented programming and moving from client/server to SOA.

Enterprise Agile Development May Be the Answer

Sustainable and repeatable success with Agile requires the same sort of framework put in place with your traditional development projects across the enterprise.  The end-to-end traceability, progress and status roll-up, portfolio management, and inter-project coordination that you have with your traditional development projects will be just as critical on your Agile projects.  After all, Agile is not the goal, it is only the path to higher quality, greater and more rapidly delivered ROI, and increased customer satisfaction.
Not only will you need a framework that encompasses all of your Agile projects, you will also need a framework which can encompass all of your projects, regardless of methodology. Doing this is likely to require re-tooling, training, and integrating multiple tools across projects.

Agile in the Enterprise Requires Top to Bottom Involvement

Adopting Agile without understanding the principles and without creating a proper ecosystem for its survival, Agile may be destined to fail. I’ve visited far too many companies whose first attempt at adopting Agile failed because the extent of their investment was a single visit from an Agile coach. In these circumstances, few people are usually on board initially, and many skeptics exist because of an insufficient effort invested in preparing for success.
Adopting Agile development requires breaking down mental barriers and building up new skill sets. There is nothing particularly hard about actually implementing any of the specific Agile practices, but many of them are counterintuitive and do take a bit of practice to get used to. Don’t underestimate the amount of effort required; it is at least on the same order of magnitude as taking a team very used to writing in C++ and moving to Java. There’s nothing particularly difficult about such a transition, but there are many subtleties which must be learned and it takes some time to build up the same base of experience.
Committing to the effort required and funding the necessary training, coaching, and retooling requires involvement from the top of the engineering organization all the way to the folks in the trenches.

Your Enterprise is Optimized for Traditional Development

Actually doing Agile development is relatively straightforward, much as going 60 miles an hour is easy to do driving on an uncongested highway. As the original challenge of fast travel was a lack of cars, highways, and driver education, the main challenge with going Agile is creating the proper environment for Agile to take root and expand.

Over the years, your enterprise has done everything it can to provide the proper environment for traditional development to thrive. But what is considered fertile ground for one crop can be a difficult environment for another crop. Consider how all of the following have been tweaked over the years to optimize for traditional development. I’m sure you can think of more.

• Where people are physically located

• The reporting structure (silos)

• Your software development tools

• Homegrown tooling and scripting

• Metrics and reports

• The budgeting process

• Skill sets, training, work habits

• Process documentation

• Fixed bid contracts

Each of these are like the rumble strips on the highway, reinforcing the form and function of traditional development. The form and function of Agile development is very different. Instead of helping, the infrastructure that is currently in place to reinforce and optimize traditional development very often discourages effective Agile adoption.  Consider the simple example of budgeting.  If budgeting is currently based on the cost of features promised for the fiscal year and governance that rewards the delivery of those exact features and punishes variances, that will not only reduce the chances of a successful Agile adoption, it will also significantly reduce the potential benefits of Agile.

Agile in the Enterprise Requires a Hybrid Approach

A full top-to-bottom transformation to Agile development will likely result in significant changes to the organizational reporting structure, physically moving people from one location to another or even rearranging their workspaces (whether it is down the hall or across continents), and changing the interaction between people at all levels, from customers and product management all the way to developers and the folks in operations. For most enterprises, a change of this magnitude can’t (or won’t) happen overnight. For most people, a hybrid environment will be part of their experience for many years. And of course, there may be some projects that you have no intention of moving to Agile.

Partnering With AccuRev to Bring Agile into Your Enterprise

The process of each of our customers is different, ranging from small collocated shops to large distributed organizations with locations across the globe, from Agile eXtreme programming to CMMI level 5 waterfall. We understand a wide range of methodologies and how they interface.

At AccuRev, our core expertise is process improvement. Adopting Agile in the Enterprise is all about process improvement. That’s why we’re excited about our new offering, AgileCycle, which has everything you need to go from where you are to where you want to be. With AgileCycle, you don’t need to worry about doing a big-bang transformation. We’ve got the expertise, coaches, trainers, consultants, and of course the tools that will allow you to transition to Agile at your own pace while smoothly integrating Agile, iterative, and Waterfall methodologies and your existing tools across your enterprise.