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. Continue reading

Collaborate to create user stories

Dialog

Collaboration is having dialog between two team members, not for the purpose to prove one’s idea, but instead to arrive at a third option. This third option would represent better thought. It is a result of validating one’ ideas with another and accordingly change your mind. The key here is that each person should be ready to be influenced by the other.

Collaboration in large teams is the collective results of dialog between members as pairs.

Team collaboration

To create product vision and stories it requires team collaboration between diverse members of varied interests. These members could include end users, customers, development teams, QA, designers, regulatories, management…. In addition user stories may be further classified to persona describing different usage patterns. Continue reading

Creating our story through dialog

A story pattern

Once upon a time there was

And every day

Until one day

Because of that

and Because of that

and Because of that

Until finally

And ever since

The above is a pattern for describing an evolving situation with no predictability on the final outcome. We know the starting point (Once upon a time), but we don’t know how the story will end. Tobias Mayer has made analogy between this pattern and Shakespeare’s style of stories.

For me this can be a drama too. Even in business and software development we can use the same pattern to describe how things evolve.

A story of a software company

Once upon a time there was a software company who was  losing money and kept shipping poor quality products to its customers late

And every day this company was in fire-fighting, receiving complains from customers and losing key people

Until one day its customers stopped accepting any further release and therefore stopped payments

Because of that they embarked to process improvement program for agile implementation

and Because of that they acquired tools, consultants and conducted training programs, infra-structural changes,…….

and Because of that they promised the customers that improvement are coming and requested  3 months break to show improvements

and Because of that they extended their agile implementation every where

Until finally the “3” months are gone and customer received the new shipment, surprise it carries almost the same issues!

And ever since the company discounted process improvement and blamed the consultants.

Process improvement instead of Agile roll-out

The above company has embarked to agile roll-out program rather than process improvement (PI) program. PI programs, in my view, are primarily discovery journey for the root causes rather than implementation of specific practices. Instead of implementing new practices,  they should have looked inward and face the factors contributing to the current state.

Let’s look at this pattern assuming we know only the starting point, end point and a in-between point as follows:

Once upon a time there was a software company who was  losing money and kept shipping poor quality products to its customers late

And every day ….

Until one day ….

Because of that they found that defects reported by QA are mainly due to poor unit testing

and Because of that ….

and Because of that ….

and Because of that

Until finally

And ever since the company produced quality releases on time

For me the blue line in the middle is a root cause that was not detected in the first scenario. Acknowledging this as impediment or constraint and building the story around it can help to mitigate the risks which contributed to failures of the first scenario.

What I liked about this pattern is that it’s intuitive. It helps people put their thoughts and probably there agony in simple way. It can serve the company to create its own destiny by acknowledging the “Because of that” then build their story to arrive at the desired end. It’s road map stated in the company’s language.

String of Pearls

The “String of Pearls” game helps  the team(s) work together to complete this story by doing whatever it takes to achieve the desired state baring the “Because of ” (constraints). The game requires dialog between team members instead of discussion. Nicely explained by Lyssa Adkins that dialog aims to find solution when two persons interact and each has good point to contribute and at the same time each is ready to give-up some of her ideas. While discussion is more like each person has interest to prove his preconceived thoughts.  Stating it in my language, dialog is solution focused while discussion is more competition based. Obviously, we need more dialogs!

Let’s assume that the team collaborated and stitched their thoughts into the following pattern:

Once upon a time there was a software company who was  losing money and kept shipping poor quality products to its customers late

And every day this company was in fire-fighting, receiving complains from customers and losing key people (as before)

Until one day its customers stopped accepting any further release and therefore payments too (as before)

Because of that they found that defects reported by QA are mainly due to poor unit testing

and Because of that they institutionalized a mandatory process for unit test

and Because of that they implemented automated unit test cases written by developers before start coding

and Because of that they mandated that developers must ensure their code passes the automated test cases before check-in

Until finally QA spent 75% less time in testing

And ever since the company produced higher quality releases on time

Finally

Rather than embarking into massive scale agile roll-out program. The company has implemented one practice that directly addressed the obvious (blue writing). Definitely the cost and duration of the implementation will be less with increased ROI. The key here was the collaboration between various groups in threading pearls through dialog to achieve the desired state. What is there “is there” and we do what it takes, given this situation, to find a solution through dialog instead of discussion (which is more ego based).