Repeated times when SCRUM or other Agile methods have been introduced, several coworkers has argued against planning. I remember that my answer usually was that Agile methods require better orderliness and planning than the Waterfall process. According to me, the Waterfall process creates a false sense of security, something many probably agrees with. Agile methods enable a superior planning as well as improved possibilities of adapting to changes in the course of the project. Speaking of changes, I find the most important factor being the new attitude towards changes. Nowadays, changes are expected, and there is a plan on how to cope with these. Similarly, the planning is constructed with possible changes in mind. In the waterfall process, my personal experience was that the project management actually was counteracting to the end, in order to fulfill the commitments previously undertaken.
On the one hand we try to plan for marketing campaigns and commitments to the customers, but on the other hand we should not plan more than necessary. The risk is that a lot of time is wasted, as in the Waterfall process, on planning components never implemented, or equally bad, the customer don’t find the function released useful, furthermore lacking other functionality. Either way, we must find a way to predict the contents of our releases. In the Waterfall process we would discuss the prediction of a time of the release, however the focus here is rather on what will be included.
Within Scrum we use Story Points, or corresponding, to estimate a certain development effort. With support from the experience of how many Story Points we can manage in one SPRINT, it’s possible to estimate our velocity. By putting Story Points on every task, we receive a better picture of what can be delivered at a certain point of time. This method requires someone to read and understand every task on a certain detailed level. No matter the size of the organization, this endeavor might be a waste of effort when the requirements are changed. In SAFe, we work with several abstraction levels. In order to create a long-term roadmap, we should work on Epic or Feature level instead. I refer to these as Epic Points or Feature Points, managing them in the same manner as Story Points. Not having to decompose and perform a detailed study of every task is one of this method’s benefits. Instead, an architect with an overall responsibility and understanding of the system will estimate the relative size of different Epics or Features, and through historical data it is possible to approximate the company’s speed of Epics or Features, respectively
Regardless if you’re using SAFe, Less or another framework in your business, a lot of information must be managed. A tool supporting the process of the company is essential. Several tools with case management as a basis, such as JIRA, has not provided the support I would like in my job as project leader or other managerial post. After numerous years of pondering and searching for a tool, I recently found an interesting ACT (Agile Collaboration Tool) which I really believe in and is currently examining more thoroughly. The architecture of this ACT is what makes it Agile. It is able to adapt according to the information needs of the user, rather than requiring the user to comply with how the developers of the tool think it should be used. My recurring opinion on choosing a tool (one of my first choices in the early 90s being ClearCase) has always been to use the tool according to the idea of the manufacturer. Nevertheless, this ACT enabled a company to work in optional manners, still receiving support no matter the managerial post.
I’ll get back to you after examining ACT more thoroughly.