Software development is an elaborate process, so many organizations follow defined procedures. But it can be difficult to keep track of every step. It is often helpful to try to visualize the complex processes involved; seeing them outlined can help you understand what needs to be completed and how to manage the overall effort.
Software development can be a confusing and chaotic experience. Teams need to complete sophisticated technical tasks, from writing code to configuring network appliances. Getting all this work completed relies heavily on the organization’s ability to divide up the work and assign it to highly skilled technology specialists.
This resulting software development process has evolved in many organizations to agile application lifecycle management (ALM), which helps clarify exactly what each stakeholder is working on and how it impacts the work of other members on the team.
In many companies, project managers track the work done by each team and report status to senior executives who are ultimately responsible for project success. The teams generally depend on processes to ensure that the work gets done on time and within organizational constraints. IT governance and the information gathered from tracking work help identify when resources are insufficient to complete key deliverables on schedule and within budget.
Understanding what is involved with these complex processes can be challenging, and skipping a step can have disastrous results, including poor quality or decreased productivity. If your job is to engineer and automate these workflows, then you have a tough task ahead. It is often helpful to try to visualize the complex processes involved in software development in order to understand what needs to be completed to manage the overall effort.
Many folks use swim lanes and mind maps to visually analyze these processes. But how do you gather the right information to create these visual diagrams?
I usually ask for a list of key stakeholders to interview as part of an assessment, so I can define the tasks to be completed, along with roles and tollgates to ensure that each process is followed correctly and yields the desired results. But it’s tough for some people to verbalize what they do in a detailed way. Some feel motivated to protect their turf and may act as insular silos. This behavior is obviously dysfunctional, but it is also all too common.
One trick I use is asking to review emails and other documents that communicate the status of workflows as they were executed. I then create diagrams such as swim lanes and review them with all the key stakeholders. You can think of this as putting up a straw man; even if team members are initially unable to tell me the tasks they need to complete, they’ll quickly correct me if I produce a document that is missing a step or two. So get those workflow diagrams created and review them with everyone involved to help facilitate the conversation.
While identifying missing steps, people also may recognize changes that should be adopted to help improve the way things are being done. Great tools are a key part of this effort.
Workflow automation tools can help define, refine, and communicate your process. What you need to avoid is clumsy ticketing systems that add more work and frustration than they are worth. The best tools allow you to model your workflows and iteratively review and improve them. Remember that processes must change and evolve.
Make sure you use incidents and problems as the catalyst for reviewing your process. When mistakes happen, they are often a result of someone skipping a step in a required process (and may indicate that you need to add another step to avoid making the same mistake again). Equally important is using opportunities such as retrospectives to review what went well and what could be improved.
The change-control process itself is a great candidate for this type of effort. I see teams use change control to review calendars and obtain approvals for deployment to production, but change-control processes often miss reviewing and discussing technical risk. Processes need to be improved, but sometimes they need to change for other reasons as well.
Your processes may need to evolve due to changes in regulatory and audit requirements, such as new rules in the banking, health care, or finance industry. Having well-defined processes that are traceable and documented is essential in many industries. Even if you do not work in an industry with heavy requirements for compliance and regulatory controls, you may find that you must respond to competitive pressures and change the way your organization is doing things, just to stay competitive. Processes evolve and mature in a way that is consistent with the goals of the organization.
During this evolution, it’s easy to get caught up in the red tape of a process, only to miss the whole reason managing your workflow is so important. Established processes can help you avoid costly mistakes and give you traceability to demonstrate that your team completed their tasks as required.
Sometimes you need to tailor processes and add additional steps in order to establish additional checkpoints, and other times you must slim your processes down to be more agile. You should never have more “ceremony” than is absolutely required. Make sure you understand your processes and have the right stakeholders involved when you need to make adjustments to be responsive to challenges and demands.
When performed correctly, process engineering can be a great tool that will help successfully manage your workflow and meet your business objectives.
See Bob Aiello at Better Software West 2016. Click here to view the program schedule.
