Make your learning experience that little bit easier
Manage your agile projects better
In our many collective years as a development house, we have been exposed to a wide spectrum of development approaches. We have witnessed and partaken in the evolution of these approaches, from the early days of XP through to the current mainstream adoption of Agile and Lean (and have been subjected to some waterfall along the way). Given the agile objective of “delivering business value frequently and consistently while adapting to changing business needs” (quoted from Back-of-a-Napkin Agile Assessment), we have learned the hard way that there are certain aspects of managing a project in an agile way that are non-negotiable if you wish to achieve the objective alluded to above.
We hope that you derive as much benefit from these lessons as we have, but without the scars of first-hand experience. The following learnings will be elaborated upon:
- Grooming
- Showcases
- Customer on Site
- Rules of Engagement
- Non-story-point Stories
Grooming
There is nothing worse than the sinking feeling on Monday morning after the weekend high, basking in the knowledge that you successfully completed a sprint, as you realise you don’t have anything to do for this one… This is especially true if you’re the project lead. The point of grooming is to make sure this doesn’t happen. As a team, you need to make scheduled, formal time to ensure you understand the next items in the backlog sufficiently. While the definition of “sufficiently” will vary, you should know enough to perform story-point estimates against those items when you begin your sprint planning. Signs that you have not achieved this include still arguing about what is required, or attempting to do solution design, during planning.
Showcases
Showcases, or regular scheduled show-and-tells, enable us to interact with our stakeholders, and ensure that we are, in fact, developing what they want. We have found that a weekly rhythm is appropriate. This also gently obliges the team to continuously deliver new functionality, as there are frequent mini-deadlines to work towards. It is great if all members of the team get to demonstrate deliverables through the course of the projects, as this both illustrates and engenders the collective ownership.
Customer On Site
It is imperative that the person whose career depends on delivering the project is available and accessible on demand. Of course, identifying that person is a prerequisite to this. Often known as the Product Owner, this role entails listing and prioritising the requirements, usually in the form of user stories. In this role, the individual must be empowered to make decisions without having to defer, and must be committed, like the proverbial pig at a breakfast of bacon and eggs. In the absence of this empowered commitment, the project will fail.
Rules of Engagement
It is vital to the team, as much as to the customer, to establish and understand up front how the various players will interact. This entails listing and agreeing responsibility and authority for the roles that are relevant to this particular project. These may comprise some or all of the following, as well as additional supporting roles:
- Product Owner
- Team Member
- Team Lead
- Architecture Owner
Establishing what “done-done” means, who to speak to if a laptop is slow, who has the final say on architectural decisions, etc, are all important to the feeling of security and certainty that enables a healthy team. These rules of engagement need to be transparently agreed to at the outset of a project, which does not preclude amendments if new lessons are learned.
Non-story-point Stories
Using story points as an unemotive mechanism for doing estimates is very attractive, but it does not cover all the activities required to deliver. This is especially true if the team sticks to the idea that story points can only be assigned to stories that deliver value to the ultimate customer. Setting up a server or development environment, identifying and managing technical debt, maintaining continuous delivery pipelines, holding retrospectives and planning sessions, and so on, are all critical to the ability to deliver, but are not valuable deliverables in themselves. By not assigning story points, a team may not cater for these activities in either the costing or the planning. It is thus vital to ensure that these “NSPs” are factored into sprint planning.
Conclusion
Agile was never intended to be an easy way out; discipline and competence are probably more important than in other, bloated approaches. Doing things wrong is not only possible but part of the process. We have learned along the way, and hope that the above points will make your learning experience that little bit easier.
