One of the fundamentals of Agile is to constantly review and question if you really need to do it at all, or if something can be done in a better more efficient way. Take the following example:
Company XYZ was building a web application and a separate administration system to manage users and settings. By the end of the second iteration it became clear that the structure of the two apps was almost identical and that they needed to share so much common code that it had to be split out into a common library. This doubled the size of the codebase, added complexity to build scripts and deployment, made testing of the software slow and became a barrier to refactoring.
At the end of the second iteration the developers questioned the reasons for having split functionality (why do we need neat logical code separation and a security split?), and agreement was reached to merge all into one, using flags and folder structures to clearly delineate the two logical areas of the application. The productivity wins were immediate.
Parts of the Agile process can be questioned too. Is keeping a burn up chart adding any benefit for our three week project? Are we doing too much management overhead for the work being done?
Company ABC had a great set of agile processes. But tasks were tracked in Jira (task tracking software) AND on a manual story board. Jira needed to match the manual story board exactly at the end of every day. It became clear that Jira wasn't being used for anything other than logging the detail of the story, the Acceptance Criteria and developer information - the things Jira does well. Jira wasn't configured to generate burn up charts, and it was generally ignored as an indicator of progress because the Project Manager looked at the manual story board and the manually created burn up chart.
It became clear that the extra work managing statuses in Jira could be dispensed with and the team agreed to only use it to keep development information and acceptance criteria. To simplify their daily routine, the snapshot of project status would be on the manual Story Board.
Tip: To make development more fun, sound an audible indicator when a Story is completed. A small bell works well.
