The software development lifecycle can be a challenging one to pin down. From company to company, there are different dynamics, processes, and people, all of which need to be navigated and aligned to establish the most efficient setup and deliver quality software.
I’ve always striven for optimum transparency without dreaded additional meetings. Keeping everyone apprised of what is happening, regardless of department or position, allows for self-served reporting. If a developer needs a task resolved from another team, they can look at their board or the linked ticket. Is it in progress? Who is working on it? They could drop them a message so that both works align and result in stronger QA (Quality Assurance).
Traditionally, each team would operate in a silo, ‘throwing things over the fence’ and waiting to see what the issues are. This does not align with a fail-fast mentality or proactive efforts to get ahead of potential alignment issues.
Speaking of QA, they need to be able to see what is in the pipeline, what is currently being worked on, and prepare documentation, test cases, and automation scripts. Project managers, stakeholders, and team leads should strive to all be looking at the same information, moving forward in real-time.
It’s hard to argue that a feature was not included or a team was not prepared when the information is ever-present.
Most teams start with a traditional waterfall structure, though it will go through different guises or different names. Essentially, an idea goes through to a BA (Business Analyst). The said ticket gets picked up by development, thrown to QA, then sits in a bucket until a release is decided to go. There are various ‘cowboy’ moments that can occur here: the BA does not seek technical validation, the developers ‘skip’ QA, QA only does exploratory testing, items are released immediately.
I must admit, I have been guilty of some of these, some of which did have some interesting/heart-wrenching moments that needed to be resolved ASAP. But those moments only served to prove to me that the process is there to protect from mistakes making it into live. No one sets out to take down a website or hose a client database.
How to get from a rough waterfall to something Agile, transparent, and reliable?
Depending on the setup, culture, and willingness to change of organizations, just starting can be difficult. Change is good, but no one likes change.
I always start with aligning one product or project, getting all work into a main place. Be it ideas, design, dev, QA, infrastructure. Getting all teams to use a common tracker such as Jira or Trello (others are available) makes it much easier to align later; plus being on the same platform allows knowledge sharing and touching into that transparency between teams.
Negotiating similar statuses and drawing all those requirements together into a single, complex process will result in a sole source of truth for all work going through a team.
Now the workload is visible, end to end. If an executive wants to know the state of a feature or a support ticket, it’s available, showing the team it’s with and the appropriate status, and more importantly, how many steps before it gets released. For the day-to-day, we need to get into some Agile meetings and segmenting the work that can be released to a reasonable deadline.
Standups keep everyone updated in a small timebox, estimations allow developers and QA to carefully review tickets, and reviews celebrate the successes of what has been completed or released.
Retrospectives are the most important meeting, and where I have seen the most amount of change to our processes. An open and honest space to say what went well, what did not, and any ideas we could implement to work quicker, better, or avoid those issues in the future. As well as adding complexity, we have had areas removed or automated to streamline our development or release cycles.
In the end, we have a single process that caters to the whole project/product team, which all members can see, and stakeholders can review or pull reports out of. It is in a constant state of refinement. There are several holes the Agile processes resolve with counter-intuitively strict rules, such as slippage, high priorities, forecasting, further refinement, and office vs. remote working, but each organization is different. The challenge is finding the balance to allow the teams the freedom to make efficiency decisions while keeping everyone else in the loop.
Mike Robins
