I’ve touched on the idea of lessons learned a few times previously, but here I’d like to address the idea directly and explicitly, as part of the Tampa IIBA’s ongoing review of the BABOK, specifically the techniques listed in chapter 10, during its weekly online certification study sessions.
Per the BABOK,
The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases.
I like this definition because while lessons learned is often thought of as something you only do at the end of an effort, it’s really something you can and should do whenever it make sense. In the following figure I show my framework for managing engagements to develop solutions for customers. It involves iterating within and between phases to ensure proper understanding, thoroughness, completeness, correctness, and internal logical consistency are achieved in every phase and for every item. However, this process does not — or at least should not — occur only with respect to the solution.
Business analysts, along with all other team members and stakeholders, should be mindful to review and improve the way they work with and communicate with the customer, and also how they work with and do things within their internal teams. This also iterative process may involve different participants in different phases of an engagement, but the iteration within and between phases remains. Note that the Project Management framework specifically talks about establishing and revisiting things like stakeholder relationships, communication, cost, quality, risk, and so on. Business analysts should certainly be cognizant of these ongoing issues as well, and many of them are addressed by the BABOK, although often in a different way.
Looking at the specific case of Scrum, we see the Sprint Review and Sprint Retrospective being conducted at the close of each sprint. These represent not only a review of the work itself, but also of the methods of working with the customer and within the internal team, respectively.
Note that the traditional sprint diagram above only includes the items on the right hand side of the diagram below, which shows how all of the six phases of my framework are incorporated into the ongoing process. This is important because product backlog items (PBIs) don’t just magically appear from the ether. Someone is doing the work to identify, prioritize, and refine them, and one of the main practitioners is the business analyst, who is often considered to be a standard team member in the Agile/Scrum framework.
The bottom line is to be looking for ways to improve everything you do, in every context, with every contact, at all times. Everything that happens can be a lesson learned.