Since the mid-2000s, “scrum” project management (PM) has been the reigning methodology for software development. Its iterative structure, frequent meetings, and clear hierarchy have made it an obvious choice for an industry subject to frequently changing customer requirements and conditions. As a result, most teams are used to managing the development process with a scrum-based project management application.
But there’s a new player entering the field with a lot to offer and not as much popularity to show for it— visual project management software. Visual PM is a modern manifestation of lean production and early Kanban tools, although it’s not synonymous with either of the two. Unlike manual methods, visual PM software incorporates elements from multiple methodologies to automate and streamline existing workflows. Packaged as a virtual system, it also carries the corresponding benefits of real-time updates, custom access controls, data analytics, and so on.
Team leaders interested in adopting visual PM often have an appreciation for its value, but are unsure how to overcome the challenges of migrating. This article will lay out best practices for making your team’s transition smooth and getting the most out of a new system.
How it’s Different than Scrum
With scrum development, team members often work on projects in veritable silos during the sprint. They collaborate and share progress at the end of a sprint or during daily stand-up meetings, which can take time out of the day. Through the use of real-time progress and task visualizations, visual PM provides complete transparency during sprints. While this won’t eliminate the need for dedicated meetings entirely, it will reduce the number of redundant or unnecessary meetings—the ones that only serve to bring people “up to speed.”
Visual PM also places less emphasis on accomplishing shippable product increments and more emphasis on working at a reasonable capacity during a time-box. This means individual story quality is prized over categorical progress. Many times, visual PM software even places caps on the amount of work in progress (WIP) a given team member should own at one time (this is found in many Kanban-based systems, which use “cards” to move individual tasks through a repeatable workflow). It’s important that each sprint yields working backlog items, but that doesn't mean quantity trumps quality; team members should be able to work at optimum capacity and give each backlog item the time and attention it deserves.
Why Some Developers Don’t Like It
Visual project management has its roots in “lean production”—a management system developed by Toyota and used largely in the manufacturing industry to cut down on waste. The implicit parallel between assembly line manufacturing and software development can be disagreeable to many developers given the nuance and complexity of their trade. And it’s true: forcing something as fickle as software development into a rigid mold won’t yield positive results.
Simplistic Kanban platforms are often one-dimensional and don’t provide the complexity that development teams need in order to stay responsive to user experience and adoption, product testing results, and a market that constantly redefines business value.
These are certainly valid concerns, but it’s important to note that not all visual PM applications are limited to basic Kanban. Many of the visual tools that have proven useful in the software industry (for example, Atlassian JIRA, Microsoft Visual Studio, and Axosoft) combine the best aspects of Kanban and lean production with the scrum foundation dev teams are used to working from, which is why some users call them “Scrum-ban.” These hybrid project management systems give teams complete control over backlogs, features testing, code repositories, and user stories with the addition of powerful visualization tools and the ability to work from a centralized, responsive interface.
But even if you’re sold on the theory of visual project management, implementing a new system probably seems daunting. There will be licensing, data transfer, and integrations to complete, not to mention training your team on a new style of work management. It won’t be a walk in the park, but with a solid strategy, switching to visual PM doesn’t have to encumber your team’s productivity.
Here are six tips for making the transition seamless and painless:
1. Set clear, realistic expectations: Since real-time visualization tools will inevitably mean greater transparency and accountability for the whole team, make sure you set clear goals for each developer to accomplish during a sprint. Your expectations should be realistic, given the length of the sprint and the amount of work each team member can handle.
2. Be flexible: Lean into the flexibility that visual PM can afford you, such as the ability to move cards into different “swim-lanes” or change assigned users and sub-tasks. This will help your team avoid assembly line mentality.
3. Use workflow visualizations to isolate problem areas: For example—if you notice that stories continuously get “stuck” in the testing phase or re-enter a later sprint due to unsatisfactory completion, use root-cause analysis to determine the reason for the bottlenecking or redundancy.
4. Reconsider the way you plan stories: Instead of pushing user stories onto team members during a sprint, let them pull stories from the backlog and populate their own lanes. This will give developers more autonomy and greatly reduce the time required for sprint meetings; you’ll only need to calculate the total number of stories to keep your team busy for a set amount of time and reconvene when all or most stories have been pulled.
5. Make sure the visual board reflects your workflow: Don’t let the newness of visual PM sidetrack you. Stick to the software development lifecycle that your team knows best. This will help them adapt quicker and recognize return-on-investment.
6. Get remote workers plugged in: It’s not uncommon for members of a development team (or entire hand-off teams) to work in different time zones and different countries. A visual PM platform can be a powerful tool for giving remote workers up-to-date visibility on team progress, and giving you the ability to monitor their work.
Case Studies
There are many organizations that have already used visual project management tools to improve their teams’ workflows and increase quantity and quality of throughput. Here are couple recent examples:
Siemens Health Services
Siemens Health Services is a global supplier of enterprise healthcare IT solutions, including software development, installation, hosting, integration, and outsourcing for hospitals and larger group practices. Their development operation spans about 50 teams, centralized in Pennsylvania, but with assets also in India and Europe.
In 2005, Siemens HS started using scrum and extreme programming frameworks to achieve their goals, including scrum teams, sprints, reviews, retrospectives, and a mature backlog process. After six years of using agile/scrum as their primary project management vehicle, they were still having trouble hitting release deadlines without immense pressure or after-hours work.
Bennet Vallet, head of Agile development at Siemens, said they decided to incorporate Kanban techniques into their workflow to deal with these challenges. “While conventional Scrum/XP provides many great practices, Siemens continued to encounter key gaps in our ability to achieve predictable outcomes, and momentum towards continued improvement in operational efficiency and quality were faltering,” he wrote last February. “Furthermore metrics based on relative story points and velocity charts were not providing sufficient insight to manage release development at this scale.”
They went all-in with the transition, deploying Kanban across teams and time zones, and at the program management level.
The Siemens teams did have access to some mildly visual tools during their sprints, like velocity and burndown charts, but they found these tools were giving them inaccurate reads due to the disparity between story types. Kanban, on the other hand, by focusing on continuous flow and work-in-progress, brought predictability and “insight into systemic problems and patterns across the value stream.”
Vallet found that Kanban helped them better embody a continuous improvement mindset, meet release deadlines by limiting WIP, and foster a collaborative environment. Even their overseas teams felt more included and up-to-date during sprints. Their cycle times fell to 43 days or less—a 40 percent improvement—and stayed within a predictable range.
Vallet told InfoQ that his teams’ results were so positive within the first year, they convinced leadership to move all product lines to visual project management, which affected over 40 teams on three different continents.
It’s important to note that Siemens implemented a mix of Kanban and more traditional agile techniques, such as incremental story development, frequent testing, continuous integration (CI), and cross-functional scrum teams to achieve their positive results. Despite the bad rap the “manufacturing” mindset sometimes has in software development, Siemens HS made an important discovery: process improvement requires predictability.
BBC Worldwide
This landmark 2009 study of a nine-person team within BBC Worldwide examined the effects of lean production and Kanban on the software development process over a 12 month period. The study was sponsored by IEEE Transactions on Engineering Management and conducted by Peter Middleton, author of Lean Software Strategies, and David Joyce, principal consultant and systems thinker for ThoughtWorks.
The BBC team—historically accustomed to agile/scrum development—began by using two central kanban boards and four “information radiators,” which are large, visual displays of a development team’s progress. The team was directed to record all tasks and stories in progress on these boards and not work on any unrecorded tasks.
Similar to the Siemens team, the BBC Worldwide team began to notice a slow shift from push-based time-boxing to a new approach, where they only pull new work as their capacity allows for it—in other words, limiting WIP. Joyce and Middleton noticed more consistent cycle times and a better ability to achieve continuous improvement, and thus, deemed the new visual PM framework a success.
Measurable results:
- Lead time improved by 37 percent
- Consistency of delivery rose 47 percent
- Customer-reported defects fell by 24 percent
In contrast with their previous scrum-only approach (where retrospectives yielded only inconclusive summaries of items delivered), the BBC team attained the fabled nirvana of “Kaizen.”
***
Although it’s certainly not for every team, visual project management tools can provide greater flexibility within development lifecycles and improved quality of the overall product through smarter distribution of tasks. Successful migration doesn’t require a complete overhaul of your workflows and business priorities—only a careful, intentional strategy and a willingness to reap the rewards.
About the Author
Aleksandr Peterson is a technology analyst at TechnologyAdvice. He covers gamification, CRMs, project management, and other emerging business technology. Connect with him on LinkedIn.