In any process there must be boundaries given that a process is a "a systematic series of actions directed to some end" *. There must be boundaries between the actions that are somehow arranged in series. For processes that are linear the series of actions falls one after the other, such as in waterfall software development where analysis comes before development which is followed by testing. For many there is comfort in this linear approach because these boundaries are obvious and for those people agile is challenging because these boundaries at first glance seem not to exist.
I carefully choose the word boundary because of its softness; quite the opposite of the use of the word "gate" in waterfall, which is much harder.
Typically the process for software development follows a series of 6 actions:
Mandate > Define > Analyse > Build > Test > Deploy
Each arrow separating items in the list represents a gate and at each gate certain criteria must be met in order to proceed to the next. What is problematic about these boundaries is that they have strict financial controls applied as part of the criteria for moving forward. For example in order to move from Analyse to Build the governance board needs to be satisfied that the analysis has thoroughly uncovered every aspect of what needs to be done to deliver. This is then contradicted by them accepting a completely arbitrary contingency of 20%.
Now, if we look at the standard illustration of scrum above we can see that work needs to move from the product backlog into a sprint and then it needs to move out into the product. There are only three actions instead of 6 - stage 1 is predominantly define, stage 2 is build and stage 3 is deploy. So, where did mandate, analyse and test disappear to? Well, they didn't disappear they just get spread across the whole process.
Mandate is the first financial control in waterfall - its where the business first considers the business case for the project. The problem with mandate in waterfall is that its sets a very strong expectation that the entire project is based upon from that point. In the agile process this mandate also comes first - the project can't start without a budget - but the mandate is referred to through out each cycle of development and adapted to suit changing requirements or market conditions without the need for a change request in the traditional sense and this is anchored to the financial control of the project. Analyse performed on a priority basis in the agile process - the most important features in the product backlog are analysed first in packages that can be deployed as useful and valuable functional units before the remainder of the software is finished. There is also a degree of analysis that continues through each build phase of each cycle too. Test also runs the entire length of the agile process. As part of the definition in card conversation confirmation with user stories testing starts with the satisfaction criteria that come out of confirmation - the whole ccc process essentially tests the requirements. When a sprint starts the testing team can review the satisfaction criteria and start to create test scripts while development commences. And within the development, test driven development techniques ensure that testing is a daily activity for every programmer. Also during development the customer may be engaged to solicit their feedback in customer reviews which essentially is acceptance testing. Finally in the deployment phase a final test is executed before the code is released.
So there are boundaries in agile software development that give it structure.
The business case is presented and a budget set around some high level requirements with an acknowledgement that their eventual delivery and detail may be influenced by changes in the business requirements as the project proceeds. The approval of that budget is also set against a plan of iterative delivery over a sustained period so the budget is time and materials rather than fixed against scope.
One by one packages of defined requirement are passed across the first boundary into build. This happens at the beginning of every sprint. To get across this boundary there the financial control is simply to say this set of requirements can be developed and deployed in isolation to the remainder of the project and within the time and materials contract the business agrees there is value in doing so – tick in the box and off we go.
When the sprint is finished the unit testing will be finished and any functional or integration testing will be complete too – in fact everything that is necessary to say this code can be deployed and it will deliver the value the business expects from it – happens in the sprint. Once that has been achieved the work can cross the second boundary into the deploy stage.
I hope this helps to convey that these boundaries and structure do exist in the agile process. In order for it to work properly agile needs to be just as disciplined as any other software development process so as for those who feel “agile is a bit to ad-hoc” or “a bit too loose” – maybe they don’t understand it well enough.