Agile is an approach to processes that allows you to get with constant change. A software development life cycle that uses an agile approach meaans that the software is being developed in a way that allows teams to deal with the need to handle business needs that may change quickly. As with many systems, there are advantanges and disadvantages.
Where Did Agile Come From?
Agile came from the software development world, where it was found that the traditional waterfall method of developing software was just not the best approach. In 2001 the Agile Manifesto was published, by a group of software engineers that wanted a better process for developing modern software that solved the issues they were encountering with the traditional waterfall software development lifecycle.
Individuals and Interactions Over Processes and Tools
So the theme of this part of the agile manifesto is that we should be less focused on the tools and more focused on the relationships or interactions. But how much. What is the split. I think in some organisations people see these things and take it too far and assume it means that every meeting should be face to face.
How does that work in global organisations where people may not even be on the same continent. So I think in this point teams need to be realistic and say meeting should be face to face where possible and practical. You can get just as much value out of a phone call or a webex or even a video conferencing call, and have face to face meetings when you can or mix and match.
Working Software Over Comprehensive Documentation
Im sure this originally meant that teams shouldnt get bogged down in documenting every little twist and turn of the software process or the software. Unfortunately these has become and rubber stamp for no documentation being created at all. There are varying levels of documentation for software, but also there are different ways to document software. Automated tests are seen as a way to document how software works with unit tests checking individual routines and functional and integration tests documenting at a high level. The main issue with using tests as documentation is how good they are and how well they are maintained, and this really depends on the buy in of the team for using the tests as documentation.
How Does Agile Software Development Work?
There are some fairly standard ideas that come up in the Agile process, that have been used as the engine to drive the need for rapid change and improvement. Some I agree with some I dont agree with.
The Agile Workflow
The key part of the Agile process is to have an interative software development process that follows a workflow in each iteration. Each iteration of the workflow has a fixed length, usually 2, 3 or 4 weeks depending on which works best for the environment. The amount of work done in that time should be restricted based on the available resources and the ability to complete agreed target within the scope of the iteration.
The iteration should result in the completion of some milestone in the project. That could be something like completion of a particular part of the software, or it may be documentation complete, or it might be hardware put in place. As long as the scope of the iteration is agreed it allows progress to be made towards the overall goal. During each iteration team members and stakeholders should be providing feedback to ensure problems are dealt with as soon and possible.
Typical steps in an Agile workflow are:
Requirements Gathering
The traditional SDLC approach of waterfall tended to be all or nothing, in that all the requirements for he whole project were gathered up front. This meant that the analysts would go to the business or customer and try and get a brain dump of everything that the customer needed to make the project work. The customer would expect the project to take a long time so would throw in everything including the kitchen sink, just to make sure they got everything they wanted. Often this could result in the customer getting something very different from what they needed which they wouldnt know till the end of the project.
Requirements gathering in the agile world is more of an iterative process. You work with just enough the get the next iteration done. You do have an overall view of the end goal, but rather than trying to eat the whole pie in one bite, we take it in small slices that we know we can achieve.
So the customer will then tend to ask for things that they need first, so the largest priorities that can be completed in a reasonable amount of time tend to get achieved first. Also because the iterations are shorter, the customer sees progress and can quickly provide feedback if it appears that what they are getting isnt taking them in the direction that they need.
Instead of the waterfall approach of large specifications, requirements are gathered by capturing user stories. These tend to encapsulated a smaller deliverable which may represent some functionality in the software or testing of a particular change, with the focus being on delivering something that adds value to the customer and the project within the iteration.
Daily Stand Up Meetings
To help the project move forward at a rapid pace, to keep everyone updated and to keep teams on track, regular daily meetings should be a normal part of the process. This allows everyone to communicate on progress, and also allow issues to be highlighted quickly. The aim should be to keep the meetings brief, and any problems that need a deeper dive should be broken out to be worked on separately.
Review Progress and Share
At the end of the iterations its very useful for members of the team and also stakeholders to provide feedback and share it to help improve the process and progress. If this doesnt happen then its likely that any issues seen are likely to be repeated in the next iteration.
Does Agile work? Just like any tool, when implemented correctly it works. However, throughout my career, I have witnessed it being implemented incorrectly, whereby one environment after another had contorted the methodology to fit very outdated, inefficient processes, as opposed to re-evaluating the process to fit the methodology, which would have rendered an optimum result.
Will Agile work in our environment? Agile has been successful in numerous environments, large and small, including some environments with the most stringent standards; for instance, Healthcare, Banking & Finance, Insurance, Technology and Retail with Payment Processing, to name but a few. Agile isn’t always a quick flipping of the switch, however. This is why I have coined what I refer to as my 35/35/30 rule. When implementing Agile, 35% of the group will jump on board with no question, another 35% will convert over after some period of time, and then there is 30% that will not move and will have to be, let’s say, urged to move over. The biggest issue with the 30% is that they can drag down the other 70% if executives do not mitigate this challenge promptly.
The problem I see with Agile is some of the practices that come along with Agile are very good and useful… and some really have no benefit at all. The issue is that it seems to be all or nothing for many. Plus sometimes people get so caught up in the process of Agile, that they actually forget that the point is to complete the project.
For instance in Agile projects I have seen people become obsessed about Kanban boards, as if those are the be all and end of a successful Agile project.
Another problem is that the Agile manifesto left a lot of room for interpretation. This means Agile means different things to different people, which is a challenge. If you have a Scrum master that wants to stick religiously to a specific way of doing Agile… and everyone else is more flexible and vice versa… it can be problematic also.