Archive
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.
Lean for Knowledge Work
Agile methods promote experimentation to discover the unknown and desired product. Please see my post here. Not all software or IT projects require experimentation as noted in the post. Harvard Business Review article here suggested that Lean philosophies are well applied to non experimental IT/Software projects. Such projects will benefit from Lean approach in a way that can not be obtained from applying Agile methods.
Read more…
Managing Large Lean Software Projects
This post based on my reading of Henrik Kniberg’s book Lean from the Trenches. I am not going to write a detailed review on the book but rather I provide my own interpretations.
Maturity in using the tool
Either Scrum, Kanban or XP we should avoid getting obsessed by any one. Instead use them according to the situation. They can be helpful in providing guidelines but they can be tweaked wisely to the environment. Our approach for managing development or project should be composite rather biased to specific method or technique. Read more…
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. Read more…
Addressing the needs of people and business
Process improvement has been doomed to be a waste function by many organizations. From my background, many who work in process improvement are treated as compliance workers instead of being contributors to the bottom-line. For me process improvement is the business. Every day we take decisions to get certain benefits. Read more…
Set-up which Kanban serves us more
The setup is a project involving sub-contractors from different vendors working in highly regulated industry.
The objective is how to make these diverse skills work as self-organized team?
The challenges are:
- Strong command and control culture.
- Non streamlined views on how work needs to be done.
- People work independently with fear to become inter-dependent.
Daily backlog prioritization
Currently I work with a team which its product is time sensitive for revenue generation. The requirements arrive in sporadic pattern and changes are the norm. Without going into the details of how effective product management is, we are required to deal with situation for increasing revenue.
Apparently we used Kanban for managing the product development of this team. We included 3 minutes for backlog prioritization as part of the daily stand-up, which served to:
- Address the volatility of cards prioritization, specifically mitigated the development of unnecessary cards.
- Product owner was able to have cards just-in-time when developers are about to have available capacity.
- Product owner managed to lower the speed of creating cards if development team is full so that she got chance to enhance requirements. This improved the quality of requirement to the development team.
- Reiterated that the team works on the highest priority cards.
A key policy is to provide the product owner feedback within a day from adding a new card. This has implemented technical risk assessment and meaningful collaboration between the team and product owner.
Manual visual board to improve measurement
In this post I describe a perspective of visual board when it’s used with an automated ticketing system. In current project which I facilitate its Kanban implementation I introduced a practice of process review. During which we found gaps between the board and the ticketing system, for a given card we can have:
- Visual board is correct state while ticketing system is wrong: This was the case for the majority of cards having inconsistency issues. This is rather easy to fix by agreeing and communicating instructions with team on the mapping rules between the states of the Kanban board and those of the ticketing system.
- Both states in the visual board and ticketing system are incorrect: This was failure in the process implementation and would require that we may change our mind on the implementation approach.
- Visual board is incorrect and ticketing is correct: This was very rare and in fact we didn’t encounter this situation.
Discontinuing the visual board and use electronic tool on top of the ticketing system can lead to drop in the Kanban process implementation. The visual board allowed:
- Collaboration among all team members to discover issues which otherwise could not have been found if we use electronic solution alone.
- The manual board can act as data validation process,which is often a missed step of a measurement system. Data captured in the ticketing system is validated against manual board which creates improvement opportunities for the whole process.
- Increased degree of transparency between what actually takes place and what is being reported.
- As corollary of previous point, the implementation of the visual board has raised the morale level of team members and improved trust.
- Produced accurate data to top management for deriving the overall process improvement.
The ticketing system is not the process; instead it’s a tracking system to help in implementing the process. The real process is what happens at the visual board, and by implementing the agreed on mechanics of engagement among team members. We can’t rely on the data of the ticketing system if the manual implementation of the process is unclear. The data is reflection to a process and in the absence of the process the data can be misleading.
Having a manual board for 2 months period or so before introducing a tool on top of the ticketing system is my preferred approach. This will allow the process to be substantiated among team members and to produce meaningful data from ticketing system.
Reflection on waste
This post describes my own view on waste in software development. I recommend reading Mary Poppendieck’s book here. I was inspired by discussion with a bit frustrated product manager who mentioned that unless the organization understands how waste harms the bottom line, chaos would continue. Read more…
Commitment in Kanban
In previous post here I suggested that historical data should be used for estimation and establishing of SLA. In this post, I talk about how we can give the up-streams dates for completion. The up-stream are those groups responsible on replenishing the back-log, who can be product managers, clients, marketing, management or others. The back-log card should contain the target date which the up-stream wants confirmation as early as possible on its viability. The first stage of Kanban board should address the following:
- assessment of technical risk
- establishment of technical solution to implement the requirement
- solution architecture
- task breakdown (e.g. graphic design, middle ware,…)
Estimation is embedded in first stage, however, it is being refined based on negotiating the solution between developers and product owner based on the constraints of cost and time. Doing sizing in the pre-sales cycle is almost always going to be changed when the backlog item is pulled to the development team in addition of waste creation as discussed in the above link.
The first stage of Value Stream should be the fastest. This in-order to provide quick feedback to the business on the viability of achieving target dates. The knowledge derived from this first stage can affect prioritization as well and should improve hand-off between business and development team. We can only commit to release date as we complete this stage.For me I would recommend board design to allow fast pulling of card and add completed cards into the queue of the next stage.
Accumulating backlog items to the backlog imposes high risk on our delivery ability and to satisfy the business users up-stream. Items which remain in the backlog can become obsolete and by the time they are pulled to the first stage the client might already changed their minds.
I summary use historical data to provide estimates during presales and use the first stage of Kanban board to provide commitment on release date.
