One of the biggest surprises of my career has been the slow adoption of agile development. I don’t understand why most development isn’t done using the Agile approach, because the benefits are compelling.
In this post, I will review my definition of agile since there are so many variations of the methodology available. I will then discuss using agile across multiple development locations, because this is one of the primary reasons why CIOs don’t use these concepts. Finally, I will describe the benefits of using agile.
4 basic agile concepts
1. Business and technology teams are co-located in an open area
Early agile adopters started with the core resources (a product manager, business and systems analysts, developers, testers), but this has expanded to include all resources. For example, on the technology side, having data engineers, DBAs and production operations personnel in the space is now common and can make a big difference, even if they are only there part time.
2. Test cases are written before programming commences
This “test-driven development approach” helps the developers know their code is working properly. While in reality many teams struggle to do this in advance of programming, the important point is that test cases are written, especially unit test cases which are often not captured with the waterfall methodology.
3. A “stand-up” meeting starts every day
For this, the team stands in a circle and each member of the team talks about what they did yesterday, what they are planning to do today and what issues they are encountering. Any items that require more than a quick discussion are documented and addressed later. Note that the standing component of this is important as it emphasizes the need to be brief.
4. The process consists of one-to-four week iterations, called “sprints”
Each iteration produces working code. In my experience, two-week sprints seem to do a good job of balancing the ability to complete something of value while retaining a sense of urgency. Each iteration consists of:
- A “planning game” to decide what functionality will be built in the current iteration based on a prioritized list of previously created “user stories.” User stories are high-level descriptions of the business tasks that need to be addressed by the application. They are originally created during a workshop with all the technology and business personnel and then updated over time to make sure the items with the highest business value are at the top of the list.
- The development of screen mock-ups and test cases.
- Coding and integration testing. Of note is the fact the code is merged often to a common baseline allowing everyone to work off the same version so integration issues are identified quickly.
- A demonstration of the working code to the team and business or technology management.
- A “retrospective” to discuss what went well during the iteration and what needs to be done differently in the future. A best practice is to create user stories to address any opportunities that are identified during the retrospective and work on these in the next iteration, because it reinforces the concept of continuous improvement.
Distributed agile
Most organizations do not have the luxury of having all their development resources in the same physical location, and so they question whether agile can work for them. It can, but it requires an investment in technology and travel.
When I first tried agile with more than one location, it did not work well. We did our stand-up meetings by phone, and it was often difficult to understand what was being said at the other location. Our first attempt to solve this issue was somewhat humorous, and we passed the phone around the room to the person who was talking. This was still suboptimal but it led to a better idea: the use of headsets that were tied into the phone system. With the headsets, everyone could hear everyone else.
This was good, but the real turning point was the adoption of video technology. Every team member was provided with video technology at their desk that allowed them to see other members working individually or to see teams gathered together. For the teams, we purchased mobile monitors with videoconferencing capability that could be rolled from one location to another depending on where the team was meeting.
A big improvement was made when we installed monitors at each development site that were “always on.” To visualize this, think about a development room with a monitor at the end. This monitor shows the team at the other location and their monitor does the opposite, showing your development room. People who want to meet can walk to the respective monitors and talk, just as if they were in the same room. The fact the monitors were always showing the other location provided much more interaction than if the teams needed to continuously call one another.
When teams are distributed across multiple locations, building personal relationships is important and it requires an investment in travel. We found it is important to have a few members of the team work at another location for one of the iterations each year. This length of time allows them to develop personal relationships and, when they return, the relationships make video conversations much more productive.
10 benefits of agile
Here are the reasons why I consider Agile to be so compelling.
1. Incorrect approaches are quickly identified
It is well documented that taking a wrong path in technology is much harder to correct the later it is identified. Agile emphases “failing fast” by showing the business progress every day.
2. Decisions are made quickly
Colocated business partners are empowered to make most decisions. When questions arise, it is common to gather people in the agile space to discuss the issue. There is rarely a need to formally coordinate meetings that might take days to schedule.
3. Collaboration results in many benefits
Because the technology and business groups are equally accountable, there is a shared desire to achieve success. The technology resources understand the pain the business feels with the current environment, and the business resources understand the technical challenges of building the new application. When issues surface, everyone in the group knows about them, and solutions are often identified by resources working on a completely different area of the application.
4. Change is recognized as inevitable and is embraced
It is understood that no one can define exactly how a system should work at the start of a project. Many waterfall projects struggle with “analysis paralysis” because of the pressure to get the requirements right before moving on. With agile, the system is developed iteratively and course corrections are made along the way.
5. The final product contains the most useful features
Since the business participates in the evolution of the product, it is efficient at identifying the features that add value. Conversely, identifying all the requirements at the start of the project can result in functionality being developed that has limited or no use in production.
6. The environment is more appealing for millennials
It is popular these days to talk about how to engage the millennial generation. Agile is great for this, because younger employees really like the collaborative, fast-paced environment.
7. The production code is of higher quality
I once did a seven-year analysis of our metrics. One of the findings was that our agile projects had significantly lower numbers of defects in the production environment.
8. The business is more satisfied with the end result
The seven-year analysis of metrics also showed that customer satisfaction surveys taken after each project yielded much higher scores for agile projects versus waterfall projects. In fact, it was unusual for agile projects to receive anything but a “five” rating, on a one-to-five scale.
9. The technical documentation takes less time and is correct
Since the documentation is limited to the artifacts needed to do the work (user stories, test cases, etc.), it represents what has been built versus what might have been planned. Audit traceability is much better because sign-offs are specific to discreet features, as opposed to a single approval of several hundred pages of documentation. Traditional development approaches spend a great deal of time on documentation that is often not maintained or used. The milestones in waterfall development are often the creation of documentation rather than actual working code.
10. Application maintenance is easier
We all have horror stories of code that had a single point of failure because only one person knew it well enough to make changes. This is never the case with agile because multiple developers code every part of the system.
Summary
If Agile is so wonderful, why don’t more organizations use it?
First, many CIOs are not risk takers, and it is a leap to make a change in how development is done. Second, if tried, agile sometimes doesn’t work and is abandoned. The common thread of both reasons is the risk of failure, but this can be mitigated if you avoid two common pitfalls of using Agile. In my experience, Agile fails when it is a top-down directive — the project teams are told they will now be doing agile development — or the project teams are told, very specifically, how to do agile. Having a rigorous methodology for agile development is counter intuitive. The whole process is about trying many things and adopting the ones that work.
The way to make Agile work is to find a project team that wants to try it and then give them the freedom to adopt the Agile techniques that seem to make sense for the organization. You will see the results, the project team will become advocates for the methodology, and you will soon have other project managers coming to you to ask why they can’t use agile for their projects.
Author: Bob Ronan
Source: CIO
