On November 29th afternoon, during Agile Day 2010 Porto Alegre, we had an excellent experience transfer conducted by Paulo Caroli from ThoughtWorks, with his presentation “SOFTWARE PRODUCTION LINE represented as cards on the wall.”
The presentation began by highlighting Taylor and his contributions to increased industrial efficiency, with a caveat to one of his management theories, scientific management, which generally integrated productive logic with the specialization of each worker, taking advantage of these benefits by employing them at a specific point in the path to the desired construction. This set of points and their flow in the path to achieving success was called WORKFLOW, and this is where Taylor’s importance in this presentation comes in.
For Caroli, this workflow was highlighted a bit further by Frederick Brooks, who emphasized that the goal of this flow, for IT teams, would be just to create a software product; which in his view is incomplete since it doesn’t emphasize improving the development process. Another point of concern was the size of each workflow stage, which according to Caroli, when very large, isn’t interesting for direct wall approach, making simplification or stage-by-stage attack with the Card Wall strategy excellent.
For understanding workflows, a set of photos was presented next, on which comments were made about each one with a characteristic of assembly lines, but always a common point: FEEDBACK and INFORMATIVE ENVIRONMENT. Among these flows, an addendum was opened to exemplify the process carried out by Starbucks, since this is a simple, clear, and visible process.
At Starbucks, it’s easy for customers to check at all times about the speed and prediction of their service. If there’s a line, I know how many people need to be served before me; there are no people sitting waiting for their orders; after your purchase, there’s a line of cups until their execution by the barista.
This workflow represented in a card wall would make its verification as simple as what already exists on the factory floor, visualizable as previously defined. In this card wall, we would divide our stages into lanes (In line, cashier, barista, and drink ready) and make representations of people and cups on it. This way, anyone can quickly know how many people remain to be served in any of the phases instantly.
Within the software universe, we’ve had these ideas applied for some time; every software has a set of phases, and even though we now criticize classic models like waterfall, the phases are still the same, but in small doses that make all the difference, but that’s not the point. So having Analysis, Design, Coding, Testing, and Ready To GO, putting these stages on the wall gives us our workflow on the wall! For Paulo Caroli, the quality assurance phase is throughout the process; this is a team attribute!
Caroli then presented the card wall for software most used by him, which consists of backlog, in dev, in quality control, and Ready To GO, and clarified that to work effectively with this technique, you must work in pull format, so everyone pulls a task and moves when they’re free, not the opposite; no manager points, the team decides, and they know when to receive new inputs!
To work in pairs, the card wall shows when we should separate pairs, create them! The goal is to eliminate problems; work must happen as quickly as possible, we shouldn’t stop, and with card walls, bottlenecks are visible on the wall! There are cases where someone responsible is absent; this is a bottleneck… so don’t let this become visible! Holding, idle! Everyone should be visible.
Within this context come Waiting stages and Action stages! For Paulo, it’s very important to leave visible also which steps in our workflow should be priorities, which ones really represent a moment when something cannot be changed for a while, so as not to allow accumulations! Steps marked as Waiting stages should allow pauses, and these, in turn, won’t be concerning; they’re part of the flow. On the other hand, steps marked as Action stages should provide extra concern regarding long stays and accumulations.
Card walls also help the team understand its own progress, detailing even more metrics. A team can perform two projects with the same speed but experience completely different situations during their iterations. While one might complete all work only on the last day struggling, the other might be able to build at the same speed but in small and comfortable daily conclusions. For this, the team will use three measures: bandwidth, latency, and throughput, which are in this order the number of stories or tasks you can do simultaneously (the kanban defines the limit of your bandwidth per stage), the time each one takes until completion, and finally the flow rate, which considers the time in moving from one stage to another, much used for daily conclusions.
*It’s worth reading Caroli’s article on how they developed an ecologically sustainable but socio-hygienically unfavorable tactic to automatically evidence latency. Latency and banana
Next, Paulo presented the effective addition of limits to the card wall, which according to him help collective consciousness along with the pull system, promoting constant movement in the team for action stages due to the impossibility of promoting a task due to an existing limit.
According to Paulo, limits can also be added to a sequence of prioritization by elevation on the card wall, where the closer a story is to the top of the board, the more priority it has, so we can work even more reactively with team changes and process flow in a self-organized way! What’s higher is more important; each team member only executes one task at a time; there’s a limit in some stages! So everything flows with priority, and no one works outside the necessary order!
In a card wall, there can also exist below the granularity of user stories, the tasks. The card wall works with stories, which are divided into tasks, so within each phase, we would have development in new lanes like to do, doing, and done! See Alisson Vale’s blog, which talks a bit more about this sub-representation technique.
Another subdivision surrounding card walls that’s reality in any software project, even those with quality above 90%, are BUGS. For Caroli, these should be evidenced and prioritized! When there are many bugs, they should be elevated to a new lane that should be treated with rules of a passing lane; you must always leave it empty and only use it in critical moments; whoever is there is always at higher speed and is always priority!
Paulo’s presentation ended with a set of questions about which card wall refactoring was emphasized, adapting collectively during times in their team. Try to take advantage of the other dimensions of your board! Complement it with other technologies!
Software Production Line Slides
Series Navigation
- Previous: Part 2 - Luiz Faias Jr. on Building a Learning Culture
- Current: Part 3 - Paulo Caroli on Software Production Line
- Next: —
- Complete series: Agile Day 2010 Series