Queues understanding to improve productivity

I work with Agile cross-functional team who don’t meet Scrum prerequisites but still want to move toward Agile. I don’t have the authority or can sell the tenet to management to change their team set-up.

People in the team came from different departments and there is lack of understanding of queues and hand-offs. We are not waterfall, rather we are Lean concurrent parallel work in analysis, design, coding, testing and system test.

Continue reading

Resisting Visualization

Once you visualize the work, you can improve it! I have heard this in many occasions and from prominent experts. When you visualize the work,  you actually arrive at shared visible understanding which allow actions to be logical consequence. Actions are stemmed from understanding the principles of flow, bottlenecks and the five focusing principles.

Resistance means the effect of change has started. It resembles our body resistance to the medicines which indicates our bodies are actual responding. Continue reading

Blind spot of visual board

The visual board has an orthogonal dimension which we can not visualize, this is the quality of engineering work. As Agile/ Lean facilitator we should be proactive in improving such engineering competencies, even if we are non technical. I suggest implementing the following two concepts.

Maintain waste basket

For me this represents noneffective requirement management. This contains the cards which decided not to complete after we had started working on them. For me this is the materialization of risks ignored during the estimation phase. However, they can be due to:
– Requirement was a wish which we discovered later that there is no need for
– Requirement is beyond economy to be implemented
– Requirement is non feasible based on the current product architecture.

Defect escape

For me this represents noneffective engineering development practices. Defect escape is defined as “For given set of cards, it is the percentage of defects found after being DONE compared to overall defects of these cards”. This percentage should be zero. The engineering failure is more severe if this measure is non-zero for non New Product Development cards, which represent the repeatable type of work. Examples for causes of non-zero value of this measure are:
– Inadequate architecture
– Poor product owner review
– Overlooked unit testing
– In effective code review

Visual board stand-up

The daily stand-up is when the team, product managers, managers and other groups meet to learn the story and share findings. This is best accomplished on front of the visual board.

Aspects of a good stand-up, apart from number of people attending can be summarized as follows.

Coloring of various project areas, for example risks, defects, urgent tasks, delays, class of service and others can help in knowing what happening and to take appropriate actions. It reminds everyone on the previous areas and therefore coloring helps the team to focus on mitigating their impact. For example, once I see red dot on a  card I know it should  implement certain policies to facilitate flow of value.

Keep the visual board manual allows face-to-face communication among team members and other related stakeholders. The manual board doesn’t require tool evaluation, purchase, training of staffs, and others. For me a big benefit is avoiding shifting the staff mind-set from being tool driven to more process oriented. Any tool has its own philosophies and ideas that should be grasped in order to use it. This takes time and can distract team from implementing Lean/ Kanban methods.

Should be less than 15 minutes covering mainly the situation of various cards and examining the flow. Having coloring system in place helps to notice the various areas which require actions and follow-up.

Should avoid problem solving as the meeting can highlight many concerns which can be followed-up after the meeting.

Attendees should no feel as if they are being interrogated. Instead they should focus on having flow of value and accordingly contribute.

Questioning of our understanding is a key benefit from my view when visualizing the flow during the stand-up. For example, the complain in one project was that we didn’t have enough developers to address the backlog. After visualizing the Value Stream and doing stand-ups for a month or so we found that the problem turned to become we don’t have enough work to give to the developers. Many of the cards represent requirements which needed more elaboration by the product owner and should not really be part of the team current activities.

Having people identity on their cards promotes ownership and should not be associated with personal attribution. Team members would report issues related to their work and once there is delay they can accept other work. The flow is enabled by avoiding having them waiting, meanwhile we pro-actively escalate to resolve the issue.

Facilitate apart from seniority from who is attending the stand-up. This originates collaborative problem solving among the cross functional team members with minimal level of escalation.

Invite other groups to attend the stand-up although they are not part of the project.  I asked our quality director to attend, his feedback was that he learned about the team which improved collaboration  and increased the alignment with the organization.

Is task tracking a waste?

The visual board models the value stream. The stages of the value stream are exhaustive list of possible actions that could be applied on a certain feature card. This regardless whether this feature card represents new feature, client specific enhancement, requirement defect or bug. For me every stage in the value stream has analogy with method which is allowed to operate on certain object (feature card).

This analogy can be particular helpful to unify the understanding on what we could do when we process a certain feature card. Extending the use of the ticketing system to keep creating tasks linked to a ticket (card on visual board) can lead to waste due to micro management through task assignment. Instead confine the ticket to represent a card and use the visual board to:

– Provide common understanding of the value stream

– Ensure uniformity of methods which can operate in a certain card (UX, Graphic design, architecture, development, code review and so forth). This particularly can be helpful to improve the skills of people to better perform those methods. This has direct impact on quality and economy of delivery.

– A corollary to previous point, this analogy can serve to reduce dependency on single point of failure.

– Help to have consistent mapping of status of tickets in the ticketing system to the stage of visual board.

Exploding the ticketing system with tickets can be misleading because we should have business value attached to the ticket. Also, it reduces collaboration as task ticket is assigned by a team leader instead of being pulled by assignee whenever he has capacity. In general I found this creates inconsistencies.

Ticketing system and visual board are complementary. While the ticketing system is excellent for tracking, automating builds and communication with other support groups, it has limited value during the development of the feature card. Feature card development is a different game which requires high collaboration through visualization and having the ball bounces back and force between various stages of the value stream.