Archive
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…
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…
Product Roadmapping with Prune the Product Tree
This post is my own thinking on Requirements Management process using Innovation Games® created by Innovation Games Company.
When using Visual board we as team members assume that the card is the right feature to be developed. I’ll talk here about the inception of feature card. Read more…
Flow visualization game
Link to this game is here.
Overview
I work with many teams who want to reap the benefits of applying the Agile principles without feeling the compelling need to change themselves in order to follow specific methodology. Those teams are committed to quality, however, they want to do things their own way, specifically those teams want the following:
- Avoid organizational changes
- Maintain the current structure, title and role.
- A way to bridge to the new development paradigm.
- Learn and grow.
This game helps to visualize the team’s interactions for the purpose of enhancing these interactions for implementing the Agile principles. Read more…
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.
Factors affecting Agile process
Each team operates under a different context. The purpose of this post is to characterize team context using objective factors. This characterization should improve our understanding about what can matter most when developing a team Agile process. Read more…
Agile agnostic, implementation steps
First, I state that I can’t improve the process; instead they should improve their work. I found this statement helpful by allowing the team to assume responsibility on their work and to position me as coach for building trustful relationship. The last thing they should worry about is that I am going to expose their weaknesses. This step is foundation for successfully working together. Trust shouldn’t be declared instead it’s judged by the team. Read more…
Company wide visual board
As a software product company our goal is to produce high ROI quality software which the customer values. Talking about ROI means we try to maximize the business value and control the cost.
Cost originates from Investments to hire and retain talents and maintain required hardware, software licenses, training and similar cost. Another part of the cost is the operating cost for the organization, for example, rent and furniture.
From my background the operating cost is a fraction of the investments required to keep the talent and sharpen their skills so that they are capable to provide technology products.
Software development is almost solely relying on developers from various skills to achieve the goal.
Unless these knowledge workers collaborate effectively, then it’s matter of luck to realize our goal.
A typical software organization has multiple engineering teams, quality assurance, release engineering, architects, systems engineering, integration professionals, implementation consultants, and account management.
Imagine on organization which has ten teams and there is a visualized issue which clogged the flow. The issue can’t be resolved by the reporting team alone. This team might need to talk with 1, 2 or more teams in order to figure a resolution. From my experience, we usually can have the issue resolved by not more than four teams in most cases. Assume each team report one issue daily. This means that the possible lines of collaboration = C(10,4) = 210
Forgetting about combinatorics of communication complexity, these lines of communication can be assessed if we can visualize the flow with all involved teams.
I suggest the following:
- Hold 2-3 times a week visual board meeting.
- Meeting is attended by product manager and engineering manager from every product development team. A manager or senior technical person is required to attend from each other group.
- The work-flow on the visual board contains a stage for every team or activity required for delivery of value to the client.
- The card on the board can be MMF or any professional service required to enable the flow.
- A card should have target date based on the scheduled release plan of the organization.
- A card should have date when it was added to the board.
- We use red sticky to indicate there issue related to this card. As I mentioned in my earlier blog-post here?, an issue is defined as what stops us to complete the work of the card according to the DONE criteria.
- Collaborate
- Ask the teams to have their work up on the board and look at the cards existing in the stages of other teams.
- Questions should be directed towards surfacing team dependencies.
- I recommend the following four questions to be answered by every team:
- What you do in your team than can affect others?
- What other teams do which can affect you?
- Do you have any issue with one of your team cards?
- Does your team know which card to pull next?
- The previous 4 questions if thought about and answered would almost always reveal the hidden issue.
- The red sticky note should provide description of the issue and date when it was reported.
- Before the meeting ends go through the issues with the team and help in identifying people who would participate in solving each issue.
- At the next stand-up review the status of the issues and asks the directly affected team to provide a status. Issues which stay around for more than x business days should be appropriately escalated.
- The solution for resolving an issue should be assessed that it doesn’t only provide near term resolution but longer term avoidance of adding to the technical debt.
Pair programming
This blog is based on my reflections after reading of Alistair Cockburn work. I am addressing the case of Pair-Programming to improve quality and therefore reduce cost.
In software quality can be improved through increased collaboration among talented developers. In traditional models of development this collaboration was optional with high degree of formality sometimes and with irregularities in other times. By now, we are more having understanding of software as creative and highly demanding endeavour with little influence of formal processes.
The XP practices provide a collaboration forum that help guiding developers to produce higher quality software. Read more…
Ugly face of Software Sizing
For years I have been using Functional Point sizing as prerequisite for developing estimates during project planning.
