Understanding, Workflow, Delivery. These three concepts sound trite, soundbites in technology for decades (substitute Execution for Workflow during the 1990s). It is hard to overstate the value of these key ideas and it is even harder to do a good job in making them a natural part of your team’s effort. They have many enemies:
-
Tyranny of the urgent
-
Laziness
-
Personal design preferences
-
Ego
-
Meetings
-
Distraction
-
Conflict
All of these can destroy an otherwise productive team. It is a leader’s job to manage these and protect the team from them. It is the individual team member’s responsibility to manage their own work and remove as much of this as possible. It takes everyone working diligently to work smarter for a project to succeed.
Understanding
All too often we jump into projects thinking we understand what needs to happen only to find that we did not. At that point work has to be redone, time is lost and the customer is frustrated. Disciplining your team to dig in and fully understand a set of customer requirements is important. Please note that written requirements accompany but do not replace the understanding required to provide a solution. The written requirements are a tool to use but cannot replace the cognitive process of understanding.
When you start a new project, there is a natural limit because a customer will not tolerate an extended delay at the beginning of a project. You cannot charge blindly across the customer objection but you absolutely need to understand the problem domain at a deep level. This is a fine line that is difficult to walk. Using tools in a way that trap critical information is very important to achieving this balance. Have the customer provide videos of key staff performing their work function or using their current application. Customers will want you to be present and witness this, but resist. We have found it is critical to capture this in a way it can be watched over and over again by team members. Through this process real understanding can occur. Without it your team will find it difficult to remember a meeting six months prior and have trouble decoding the typed up notes neatly stored on their computers.
It can also be helpful to listen to customers talk about their vision for the project. Again, do not do this in a meeting but obtain a recording of this. New team members can hit the ground running after reviewing such valuable materials and the tools are readily available. This is not to say you cannot have meetings that supplement this information but all too often a meeting is all that occurs. It is commonplace for notes to be sparse from these meetings and our memories are notoriously faulty.
Once you capture this knowledge it is important to translate this into a set of requirements. Sometimes customers will give you these, but most of the time they are too busy and this falls on you. Follow through and process this into a detailed list of features that can be pushed into your workflow.
Workflow
There are very few times that enterprise software will be simple, and any complex project can be derailed without a clear process for execution. There can be variations by organization, but I will speak generally of the process we use. Below you see a graphical representation of our workflow.
It is important for the project lead or architect to lay out a particular piece of work. Once it is ready it should go into a bucket where all the developers on a project can see the work that is staged. We often place these into milestones, sometimes referred to as sprints. Developers pick up the work and push the item through development, peer review, internal testing, and QA Testing.
The enemies I listed above mostly rear their heads to attack your workflow. There are always reasons that make sense at the time that lead to workflow destruction. A leader is responsible for guarding the gate. If any of these are allowed into the team and allowed to take root, there is a high likelihood of project cancellation, termination, and failure. Pushing items efficiently through a workflow allow for the most important part of a software project to occur: delivery.
Delivery
From a customer’s perspective you have not really done much until they have software in their hands. Use the previous two efforts to both understand the core features and aggressively push them through your workflow. Use your understanding to plot the quickest path to putting software in customer hands for comment, feedback, and tactile success. Getting a project to that point is critical to its continued success. Completion of some limited functionality is far more valuable to your customer than partial completion of 100s of features. Shipping is golden, a lack of shipment is a recipe for disaster.
