“This happens in part because agile adoption has been practitioner-led, leading teams to focus on themselves. Areas outside of their control, such as project planning and release management, still follow more traditional approaches, so Scrum adoption is limited to the development team.” David West, Water-Scrum-fall is the reality of agile, SD Times, Dec 2011.
We hear about it everyday. Just eat this one berry based product and your health will never be better. Buy this mattress and sleep well, and your day will soar to new heights. Purchase this Project Management Tool and you will never deliver a project late again.
I am a big advocate of doing a few things right. One technique is to take one thread of the project and focus on it, getting it to perform very well. This approach helps related processes firm up and start working well also.
This notion, that optimizing one thing can help improve others, needs some elaboration.
While this might be originally a focused project (e.g., let’s adopt Scrum), what we found and hence look for is how the change also supports and encourages change in other related processes (e.g., project management, costing, quality, release, etc.). In fact, what we often — almost always — find is that to make much progress at making that single process highly effective, we must adapt (often, fix) all those other processes that feed into it and that take their output from it.
The unifying notion is that by doing any one thing well, we have to inevitably do multiple things well. Picking that single process as the starting point requires the recognition that we will spend time on related processes, making them perform better also. The single dimension becomes the anchor, but it has to anchor those other processes to gain the expected advantage.
To Do One Particular Thing Well We Have To Do Multiple Things Well
I was the new chief of computer and network security. My job was to implement what seemed like some pretty simple security requirements (e.g., quarterly changing but random passwords, separation of secure workstations so someone can’t look over your shoulder when working, secure rooms with access lists, etc.). While as simple as these rules were, it was tough to get everyone to implement them. I found myself spending time helping folks simply manage their resources (find their workstations, find rooms that accommodate extra space needed for security, etc.). I noticed, however, a simple pattern. If the person running the department was well organized and knew what they had and where their equipment was and who was using it, then adding on security was just a detail.
For folks who had no clue where their security workstations were or who was going into their secure rooms, then adding security meant first needing to implement basic department and equipment management. We would find the worst setup possible — a line of secure workstations side by side and crammed into a small room (with a huge window behind them) and the demand “ok, how do I separate all of these?” The notion, for example, that we may have to juggle multiple rooms to meet the requirements was heretical (“why is security running our department!”).
When all was said and done, we got compliments (often quietly) for getting some departments to not only get their security right, but also for getting them to finally manage their resources (e.g., their offices were no longer a confusion of equipment and wires).
So if a project management tool is seen as being a silver bullet to fix the organization (e.g., Six Sigma, ALM, Agile, Scrum, CMMI, ITSM, TDP, PMO, Prince2, etc.) then the chances of it being truly successful are increased by recognizing and planning for improving related processes.
Have you noticed and planned for how making one change will often domino into multiple needed changes?