Last week I attended the Better Agile & Software Development Conference East, and I really enjoyed the experience. The conference presented a good opportunity for organizations to come and learn about some of the common struggles facing software development from a process and strategy context.
Because of the broad topic area, the conference included a good mix of organizations in terms of size and industry. For example, there was one organization there that has a single development team, and it sent most of the development team to the conference for Agile certifications and learning opportunities. There were other organizations who hand-picked members from among hundreds of teams, with the intent of discovering fresh ideas to bring back to present to managers in the hopes of starting a conversation about ways to improve or move forward. The vast array of lines of business in attendance was impressive – software development vendors, government agencies, blood banks, medical clinics, financial firms, department store chains, process consultants and everything in between.
The conference itself seemed to focus on two common themes. The first was trouble with testing inside of the Agile framework. Testing is no less important to the development process than actually developing the code or requirements, but often testing is crammed into the end of a sprint cycle, which leads to late discovery of defects and contributes to difficulty in estimating projects.
This difficulty speaks directly to the second common theme – trouble with estimation in Agile. A large number of organizations are having trouble shifting their estimation models to fall in line with the Agile approach because of the change in philosophy and an inability to establish a recognizable cadence to their releases. This also makes it difficult to provide reliable estimates, which snowballs with the testing issues mentioned above.
Some of the tutorials I attended at the conference provided good insight into ways to deal with the problems of estimation within the Agile framework. The best example of this was taken from a tutorial about the role of a business analyst in an Agile environment when the instructor mentioned an idea that resonated immediately with everyone in the room and provided words to a concept we had all felt before – the need for a “definition of ready.”
In Agile we are familiar with the idea of a “definition of done” – aka the criteria we have to consider for a backlog item to be considered complete and moved into the “done” pile. The definition of ready is the other side of this – aka the criteria that must be met in order to consider an item ready to go into the backlog. If this criteria is not established, the backlog gets cluttered quickly and the implications are not understood to the greatest degree possible. This then makes it difficult to estimate the task appropriately and also leads to more difficulty in establishing the testing goals in advance.
I certainly came away from that tutorial and the others with some good tips for how to approach these (and other) trouble areas. Of course, it was also nice to be just a block away from Downtown Disney for some evening entertainment!
I look forward to delving further into the concept of estimation in the Agile environment (something we can help with here at DCG) and the “definition of ready,” with the team here at DCG. If you attended the conference and have any thoughts about these concepts or about the conference itself, please leave a comment! Otherwise, I hope to see you there next year!