Agile methodologies are becoming a trend in project management and software development. In 2007 a survey between 2250 companies showed that 25% of them were using agile methods. Scrum was confirmed to be the most popular agile methodology. A more recent survey on almost 500 companies showed that 40% of them were using Scrum.
Demand for a shorter time to market with an emphasis on early benefit realization has increased exponentially in today’s business environment. To satisfy this demand project teams have realized that this can only be achieved through a more collaborative approach and also by commencing projects without much understanding of project requirements.
Customers often don’t realize what is needed in order to achieve an objective until they have a prototype, which can be altered very easily to match the clients growing understanding.
Change has to be embraced, for a client to obtain maximum return of investment from every product development opportunity. Usually many projects deal with a certain level of uncertainty and complexity which can mean that there can be a set of requirements that remain unknown until the end of the project.
One of the reasons that Scrum had such a broad adoption was the fact that traditional methodologies were considered inefficient. Other factors that contributed: client’s growing demand for a faster time to market, early benefits realization.
The changing needs of the customer coupled with the fact that requirements couldn’t be changed in an effective way usually caused long delays or even worse, project failure. The need for a more incremental solution focused on early delivery while reflecting business needs has grown and Scrum looks best suited to do the job.
Agile methodologies strengths.
- Close, daily cooperation between business people and developers.
- Continuous attention to technical excellence and good design.
- Regular adaptation to changing circumstances.
- Even late changes in requirements are welcomed
- The documentation is crisp and to the point to save time.
- The end result is the high quality software in least possible time duration and satisfied customer.
Customer satisfaction by rapid, continuous delivery of useful software.
One of the strength points of agile methodologies is that its philosophy which based on the idea that projects are developed in short iterations. At the end of each iteration the user can see a working version of the software before moving ahead to the next iteration which means that the overall project will be more flexible. In traditional methodologies if the customer changes some requirement after long period such as (six-ten month)this require complete project rebuilding, but through applying agile philosophy it can be adapted.
People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other.
Another positive point in agile methodologies is that developers are often more pleased since they communicate with customers and respond to their requirements without following rigid policies in communicating with managers to take an approval for every simple modification. Flexibility does not means that developers can do modifications and respond to customers’ needs without telling their supervisors but they can respond to customers’ modifications before telling their managers.
Face to face communication within the team and continuous inputs from customer representative leaves no space for guesswork.
One of the main characteristics of agile methodologies is that it based on working on small teams. This means that there is always a continued channel for communication between team members which increase job satisfaction. Continued communications means identifying problems and mistakes earlier. Besides that working in small teams will accelerate the development process.
Customers are playing an important role in the working team. Agile methodologies recommend having a full time customer working with development team. This means that any misunderstand of customers’ requirements can be solved and answered immediately. Also this means the time taken for solving any emergent issues will be reduce to the minimum.
Agile methodologies weaknesses.
Many companies are transitioning to a Scrum exclusive environment even though it has known governance gaps. A solution that can be adopted is a hybrid approach by combining Scrum with other methodologies and mitigate the lack of Governance.
True Agile is rarely practiced.
In many cases, developers, managers and consultants alike mistake Agile for its lowercase sibling, agile, and assume that Agile is all about flexibility and absence of process. This is FALSE. Agile has formal rules and structure, though they are quite a bit different from those of other development approaches. Agile is iterative, it is adaptive and it is supported by some outstanding tools and techniques, like burn-down charts, product backlogs, user stories and stand-ups. Most important, Agile is not anarchy. It does not mean that everyone does whatever they want and there’s no sense of organization, despite the fact that you may feel this is the case.
Heavy customer interaction is essential.
Reflected in principles four and five of the Agile Manifesto, heavy customer interaction is one of the biggest benefits of Agile, but it also becomes a weakness in some environments.
- Consider, for example, situations where the customers or users of the software being developed do not have the time available to meet with members of the software development team on a frequent basis?
- What if the key customer is the CEO, who often has more important matters to address?
- What if you’re not permitted to talk with the users?
One important thing to know about Agile development teams is that they are high maintenance – they work quickly, but they also require much more time and attention from the business side to be able to work quickly. If that time cannot or will not be spared for their benefit, using an Agile approach will bring little gain over a Waterfall approach.
Agile thrives with co-located teams.
In a typical Agile environment, the Agile development team and the business users are located in the same physical location, such as the same floor and cube space, to increase interaction within the team and with the customer. This technique is highly effective, but it is also not always practical. In many cases, the line-of-business does not have the space to temporarily house the development team members. In other cases, the development team is national or international, so it is simply impossible or cost-prohibitive to have some members of the team on site.
Agile has difficulty scaling for large projects and organizations.
When run properly, an Agile development team is typically in the three-to-eight person range, being made up of the software product manager, a team leader (often the Scrum Master), one-to-three developers, and in some cases a designer, an business analyst and a tester. With its heavy emphasis on customer interaction, self-organizing teams, verbal-communication over-written-documentation, prototyping and requirements flexibility, it becomes extremely difficult to coordinate work as an Agile team grows. The scalability problem with Agile is not minor and it shouldn’t be overlooked.
Agile is weak on architectural planning.
This weak-architecture problem is only an issue when the architecture and the platform are not known or pre-determined. In many larger businesses, software architecture and platform selection are done separately from software development via enterprise architecture and architectural roadmaps, which often takes the burden away from the Agile software team. However, if the platform is not known prior to the start of the project and the architectural approach is new or unproven, then the Agile software approach will struggle to define and deal with architecture.
Agile has limited project planning, estimating and tracking.
There are tools available in the Agile arsenal for planning estimating and tracking, but as Agile proponents will tell you, there’s very little emphasis on these core aspects of project management. By design, Agile minimizes planning through the use of backlogs – prioritized to-do lists of software product features – and by fixing deadlines instead of scope. In most cases, estimating level-of-effort is done for each iteration (sprint), with only rough estimates for each release. This lightweight planning, estimating and tracking process suits small, non-strategic projects well. But often is not acceptable when the customer is a third-party who requires scope and cost defined via contract or a senior manager who wants to know what will be provided, when it will be done and how much it will cost.
Agile requires more re-work.
Because of the lack of long-term planning and the lightweight approach to architecture, re-work is often required on Agile projects when the various components of the software are combined and forced to interact. In Agile-speak, this is roughly called “refactoring” and it is both expected and budgeted for in each iteration after the first. Certainly, refactoring has its benefits in that one team member does not have to wait for the other to begin work. However, in a worst-case scenario, major portions of code may need to be re-written when two or more developers are not in sync, resulting in higher and higher re-work costs as the number of iterations increases.
Challenges making contractual commitments.
For many projects, the client and/or senior management want commitments about the triple-constraints – what will be provided (scope), when it will be provided (time), and how much it will cost (cost). For Agile projects, in particular, it is extremely difficult to prepare estimates for fixed-bid contracts and its not uncommon to see senior managers pound their fists on the table when they fail to received detailed estimates.
Agile hinders business continuity and knowledge transfer.
By nature, Agile projects are extremely light on documentation because the team focuses on verbal communication with the customer rather than on documents or manuals. As a result, a switch of a single team member, much less an entire development team, away from one product and over to another can significantly impact the organization’s ability to maintain and improve that product. Much of the knowledge resides in the team’s head and is gone when they are.
How do you feel about Agile Methodologies? Are they the future, despite having some important shortcomings? Leave your comments below.