Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
How to reduce cycle time? It is an important question, especially because reducing cycle time is probably the holy grail of software development. Generally, an improvement in nearly any software development metric should improve cycle time. It’s a good bird’s eye metric for how well engineering managers and team leads are doing. Cycle time is so important that it actually is worth obsessing about. Nanoseconds count, just ask the NYSE. As we only live an average of 2.5 quintillion nanoseconds, it’s a wise DevOps manager who makes them all count!
Cycle time, for our purposes, is the time between when you start and finish work on a task. It does not include any time a task sat in a queue waiting to be started. For more depth about cycle time’s role, check out our earlier article on Cycle Time in relation to Lead and Takt Time.
Every validated improvement in cycle time provides the potential to improve cycle time further. Validated in this context serves to emphasize as (our CEO) Renata Pataki advised, “an improvement in any other metric that leads to a decrease in quality is not an improvement.” Improving quality is always the control for validating any change in process. That said, improving cycle time translates to:
Two more items should also be inherent to this overall process – efforts to improve team collaboration and continuous skill growth. These two components are really at the heart of the process and are built into it with daily standups, code reviews, mentoring, and retrospectives.
It helps to take a step back from the lines of code to see just how beautiful the Big Picture is and how everything fits together. Yes, yes, resistance is futile.
Where to even start? Start simple and add complexity only as needed.
Much as with taking the time to properly define project requirements, it’s worth being clear about task requirements, too. More ambiguity equates to more room for misinterpreting the task. Tasks are usually defined in the project management software you’re using (Jira, Trello, Monday, Wrike, Clickup, Asana, TeamGantt, Backlog, ProofHub, Zoho Projects, the list goes on…). That there are so many PMS options is a subtle indicator that people have issues with their PMS options. The remedy is almost simple: a) make sure your team is trained on your PMS, and b) set a clear standard for defining and tracking tasks.
Complexity and difficulty is subjective. Story points are an estimation of the quantity of work, complexity and uncertainty associated with a task. Though not always more accurate than “time-based” estimates, story points are more flexible as they aren’t tied to individual skill levels and don’t need to be “resized” if something changes. If something does change (a team member goes on vacation or the team’s efficiency increases), you can adjust the number of story points with each sprint.
The poker system assigns points in a democratic fashion (secret votes that are simultaneously revealed). Substantial variations may be discussed or you may simply assign it the most points as Planning Poker suggests if you have a mature team. It’s useful to define and share examples, conditions, and characteristics of story point values so that everyone has a common point of reference.
Most teams use the Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21) as each increment is noticeably different (~60%). Instead of quibbling over whether a task is a 3, 4, or 5, assigning it the highest value still accommodates everyone. It reduces the risk of the task spilling over into the next sprint. If someone finishes all of their tasks early, they can either help others finish their tasks or take a new one from the backlog. Either way, it’s all reflected in team velocity which is helpful in planning future sprints. This doesn’t improve cycle-time per se.
Small is relative. Though story points may not equate to time, there’s likely some loose correlation. Some tasks might take 6.048e+14 nanoseconds (a week for you non-obsessed types out there), others just a day or a few hours. Trunk-Based Development and Continuous Integration (Delivery and Deployment) efforts advocate for frequent commits (daily or even more frequent) to allow for fast feedback.
Experienced developers likely already know how to break up their tasks into smaller pieces. They might need to be called upon to assist your Scrum Master in defining logical divisions of tasks for less experienced team members.
Scaling teams efficiently is one aspect of improving cycle times. Agile promotes cross-functional teams with 3 to 9 members, with 7 team members being close to an industry average. It’s worth reiterating Conway’s Law, “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” As noted there, team size can be impacted by the manager’s capacity, team-member cross-functionality, project complexity, financial restraints, and project stage.
Leastwise, bigger teams don’t equate to greater productivity or efficiency. Larger teams inherently equate to increased inefficiency and complexity – it’s something that we bump up against in several different ways (like communications and code review/approval processes).
This is not to say that you can’t have “bigger teams” – the ultimate goal is to create teams of teams. Or to quote PerceptionBox, in attribution to Brigadier General (US Army Ret.) Bernard Banks, Ph.D. in his discussion of Agile team development,
Sometimes developers have questions. Our increasingly post-apocalyptic distributed work environment means you can’t throw a paper airplane at a developer to get an answer to an urgent question. Everyone on your team may be working in different time zones, hours, and days. This warrants establishing priority-based communication protocols as we shared in How to Manage Distributed Agile Teams. We have a variety of tools like Slack, Zoom, Sococo, email, and mobile phones to accommodate fixed, routine, casual, urgent, and SHTF communication requirements. Efficient communications may not always improve cycle time, but inefficient comms can really hurt it.
Our expertise here at Gitential is in providing advanced analytics to help software development teams improve their speed, code quality, coding efficiency, and team collaboration. A variety of reports help software engineering managers to see and better understand their team’s coding behaviors and proactively mitigate delivery risks. In terms of process, automated analytics makes it easy to spot issues, examine the impact to better understand why it’s happening, and take action to resolve it.
Software development is complex, analytics provides a data-driven way to evaluate team and project health. The benefits apply to help developers improve their coding speed, quality, efficiency, and teamwork skills. Managers can also put the analytics to work in optimizing teams around project requirements – as with specific languages and complexity levels.
Holistically speaking, by improving one metric, you’re likely to influence improvements with several metrics – up to and including reducing cycle time.
Shameless plug, but we welcome you to give Gitential a free try!
One of our main use cases helps to understand how one team’s code complexity increased as it added new team members. Increasing team size inherently increases complexity. Adding new team members inherently increases inefficiency. The team would have been better off adding one or a few developers with the specific expertise needed for their project vs adding fifty contributors.
Teamwork is the key to tackling anything, including efforts to improve teamwork. The insight gathered from software development analytics can be used when pairing developers for code reviews, mentoring, daily standups, retrospectives, and even continuing education programs.
With each retrospective, your team can choose 1-3 metrics to try to improve and how to track progress. A moment or two in your daily standups can be used by the team to share tips for improving each metric. Code reviews and mentoring assignments based upon language skills and experience can help develop team skills in two languages (almost) simultaneously.
Again, efforts to improve one metric ultimately help improve a few metrics, ultimately helping to reduce cycle time. Over the course of a year, your team can cover 26+ different metrics.
The greatest improvements to cycle time are likely to come through automation, starting with Continuous Improvement (CI), and onto Continuous Delivery/Deployment (CD). These steps need to be guided by Agile methods and practices with a DevOps mindset in applying tools to automate work processes and testing. Both CI and CD seek to enable developers to push their code deeper down into the distribution funnel – reducing the need for human intervention to review and approve their commits.
The 2020 State of DevOps report by Puppet directly ties human intervention or “orthodox approval” to inefficiency, scaling more or less proportionately to team size. Going back to their 2016 report, they showed that teams with mature/high-performing DevOps (employing CI/CD) deploy 200 times more frequently than those with little or no automation. But, more than that, their lead times were 2,555 times faster, had mean time to recover rates 24 times faster, and all with a 3x lower change failure rate. Teams with mature CD capabilities are deploying multiple times per day instead of once every few months.
Perhaps the most complex part is automating the testing in production-like environments. However there are many services available to do that as we covered in Continuous Delivery/Deployment. Between their ML/AI, advanced pattern analytics and algorithms, computers can process in far fewer nanoseconds than… carbon-based lifeforms.
It’s worth obsessing about improving cycle time, to a point.
Article updated: March 30, 2022
