February 4, 2012

Posts Comments

BigVisible Blog

A coach’s moral dilemma

January 11, 2012 By Alex Singh 10 Comments

A fellow coach recently asked me for my opinion on an ethical dilemma — was it morally right for us to show people a new way of doing things knowing fully well that we were setting the group for eventual disappointment. Disappointment in his case is inevitable and will start setting in as soon as the parent company begins assimilating the subdivision and mandating that the latter operate under the parent organization’s restrictive rules and policies. My simple and somewhat glib answer was that we were doing the right thing by helping people get better and were providing them the wherewithal to make informed decisions about their future career. And, if in the end, the employees were unhappy they could take their knowledge elsewhere to an employer who would value their expertise. [Read more...]

Filed Under: Agile Adoption, Agile Coaching, Agile Transformation, Enterprise Agile, Leadership Tagged With: , ,

Top 7 reasons for lack of creativity in an organization

January 9, 2012 By Alex Singh 1 Comment

Summary:

  • Leadership is crucial for defining a shared vision and generating buy-in from employees.
  • C-level managers are responsible for creating a learning organization that values systems thinking, craftsmanship, and team learning.
  • C-level managers must design an organization whose structure, processes, metrics, rewards, and talent align with the organization’s mission.
  • Managers are responsible for creating a well-trained, well-organized, well-managed company. If people require constant supervision then management has failed to do its job.

Last year, the new CEO at a client decided to leapfrog existing competitors by creating an innovative product; a product that would attract customers and cause competitors to play catch-up. A team that included the best developers, in the company, was hand-picked; the business was told that cost was not a concern; and the group was secluded from the day-to-day madness and allowed to focus on getting the job done. Despite this the program was a failure and ultimately the task of innovation was “outsourced.” What happened?

A number of major shortcomings inherent in the existing culture doomed the endeavor from the start; these shortcomings were very visible to outsiders but not to long-term employees. Not all organizations face all of these shortcomings — based on my experience, these are more prevalent in larger organizations.

  • C-level managers not creating a learning organization
  • Lack of a compelling vision
  • Lack of prioritization and understanding of what is truly valuable
  • Org structures and policies that stifle collaboration and communication of ideas, information, and feelings
  • Reward/merit system that punishes innovation and risk taking
  • Overly focusing on utilization
  • Perception that senior management does not walk their talk

[Read more...]

Filed Under: Enterprise Agile, Experience from the Field, Leadership Tagged With: , , , , ,

There is no one definition of Agile

December 22, 2011 By Alex Singh 1 Comment

A few weeks ago, I asked my co-workers to distill the concept of Agile/Lean to its simplest essence and do it in no more than 10 words. The statements had to clearly convey what Agile was really about and why anyone should really care about it.

There were two reasons for the request:

  1. I recently critiqued a 2-day “Introduction to Agile” class by a coach-in-training. Everything that I expected was covered in the class but I felt the lack of an underlying theme; the content didn’t seem to fit well together.
  2. I wanted to understand whether Agile meant the same thing to different people and whether they emphasized the same points in their class/presentation.

Here is a sampling of the responses I received.

  • “Deliver value frequently at a sustainable pace while adapting to business needs.” — Brad Swanson
  • “Be one with the customer.” — Steve Johnson
  • “Sense & respond quickly to changes that have measurable value.” — Skip Angel
  • “Do the right things sooner.” — Jonathon Golden
  • “Agile is about knowing what NOT to do.” — Mike Dwyer
  • “Continuously adjust our actual process to reflect our improved understanding.” — John Ryan
  • “Utilizing continuous prioritization and feedback, collaboratively develop incremental business value.” — Jim Elvidge
  • “Continually improve value delivery via experimentation, feedback, and retrospection.” — Alex Singh
  • “Do Something, Self-Organize, Inspect & Adapt” — Scott Dunn (stolen from Aaron Sanders)

Not surprisingly, people emphasized different aspects in their distillation. I assume that these are the same things they emphasize when coaching teams and organizations as well. It is important to note that everyone is right and no one definition is better than another; people with different backgrounds emphasize different things and have a different worldview.

What do you think is the intrinsic nature or character of Agile that makes it what it is? How would you define the most important aspects of Agile in no more than 10 words?

Filed Under: Agile Coaching Tagged With: , ,

Moving beyond the 5 Whys

December 19, 2011 By Alex Singh 1 Comment

The 5 Whys technique is a critical component of the Toyota Production System. Taiichi Ohno, described it as “the basis of Toyota’s scientific approach … by repeating why five times, the nature of the problem as well as its solution becomes clear.” The underlying premiss behind the method is that a questioner can trace the chain of causality by drilling deeper. The questioner begins with the problem statement and repeatedly asks “Why did that happen?” multiple times to clarify cause/effect relationships.

In software development, however, the technique has some shortcomings:

  • Problems and their causes are not always linear and you cannot always trace a symptom directly to a root cause by asking the 5 Whys.
  • Sometimes causes are separated, in a significant manner, by time and space from the effect; this makes identification of the relationship difficult.
  • Practitioners at times aim for the single root cause, but each question could elicit many possible root causes.
  • The 5 Whys technique works well in simple and complicated environments; not so well in complex and chaotic conditions (see the Cynefin framework for definitions). Multi-causality, contributing factors, and not-so-obvious variables if ignored can lead the questioner to the wrong conclusions.
  • Results are highly dependent on the questioner’s ability — stop too soon (at the symptom level) and you don’t reach the lower level root causes; stop searching after the first right sounding answer and you miss out on other plausible causes; treat a long-lived and unchallenged statement as fact and you limit avenues of investigation.
  • The questioner’s level of knowledge is a limiting factor — ignorance can cause people to overlook causes they don’t already know about.
  • Results aren’t repeatable and different people can identify different causes for the same problem.

It’s important to realize that we have more than the 5 Whys method in our toolkit. We can flow chart the process, use the Current Reality Tree (CRT) thinking process, or use Gerry Weinberg’s Diagram of Effects (my favorite). Which techniques do you use?

Filed Under: Agile Coaching, Experience from the Field, Facilitation, Tools Tagged With: , ,

What the Scrum!

December 15, 2011 By Alex Singh Leave a Comment

The point of the daily scrum is not for each team member to address the 3 questions in order:

  1. What did I work on yesterday?
  2. What am I going to work on today?
  3. What are my obstacles/issues

Please realize that the questions are just a mechanism for ensuring that everyone understands:

  • What’s blocked?
  • What’s being worked on?
  • Who is working on X?
  • When will X be done?
  • What am I doing/supposed to be doing?
  • What are everyone’s top 3 priorities?
  • What will be done today?
  • What’s ready to test?
  • What issues need to be discussed?
  • What is critical?

ScrumMasters, your facilitation skills won’t amount to a hill of beans if everyone attending cannot satisfactorily answer (for themselves) these question after the daily stand-up. Don’t get hung up on the procedural nitty-gritty (the rituals); aim for understanding instead.

 

Filed Under: Collaboration, Experience from the Field, Meetings Tagged With: , , ,

Visualizing Project Risks and Impediments

December 13, 2011 By Alex Singh 1 Comment

I like electronic tools but have found their efficacy to be rather limited when it comes to capturing project risks and having people actively manage those risks. Often I come across Project Managers who are really good at documenting every conceivable risk but who aren’t as conscientious at proactively managing those risks. Sometimes, formal risk documents are used as a CYA mechanism instead of as a means for driving down project risk.

I found that a large information radiator for displaying project risks and issues has been well received by clients. The version I use is a simple 2×2 matrix. The two columns are used to classify items as Business or Technology related; the two rows to show whether the items are Execution or Coordination related — teams that aren’t smitten by the categories are free to change the headings to whatever makes sense in their context. Concentric rectangles denote when the effect of a risk will be felt.

Risk Radar Chart

Sample Risk Radar Chart

Items in the inner-most rectangle (or square or circle) identify current issues (risks that have come to fruition) or risks that will become issues within the next two sprints if not handled. The next outer rectangle shows risks that the team foresees materializing within the next 4 sprints. Longer timeframe risk items go outside the 4 sprint rectangle.

Color coding helps denote the severity/impact of the risk. Reds and Oranges affect the project more negatively than the Yellows and Greens. The Sunburst item in this case was a showstopper that was going to bring the project to a complete halt. The areas on the extreme right were for items that weren’t deemed worthy of being tracked on the risk-radar board just yet or for risks that had been taken care of.

For teams the goal was to handle risks before they became issues. Ideally, the innermost rectangle should be empty — teams should be proactively mitigating risks and taking care of them before they get into the innermost “Next 2 Sprint” rectangle.

We used large foam boards and masking tape for creating these risk-radar charts. The chart was prominently displayed in the team room and could be referred to during meetings.  The light weight foamboards made it easy for one person to carry the chart from one room to another if a meeting was being held elsewhere. Pictures taken with a digital camera were emailed to off-site participants.

Once a week, the Product Owner and ScrumMaster would meet with the development and QA managers and with business and IT stakeholders to review progress and roadblocks. During this hour long session, the group would discuss the issues and risks starting from the innermost rectangle.

This meeting served four purposes: (1) as a risk escalation mechanism, (2) as a mechanism for managers and stakeholders to remove impediments that were too big for a team to resolve on it’s own, and (3) as a mechanism for moving away from the existing one-way status reporting culture — managers and stakeholders were expected to report on progress (or lack thereof) on items they had publicly taken ownership of during the previous meeting, and (4) as a way for keeping managers from harassing the teams to “go faster”.

The reason this chart worked surprisingly well was: (1) it was always in everyone’s face and was hard to ignore, (2) managers had insight into risks and impediments and could proactively smoothen the way for the teams, (3) managers realized that teams could not go faster until the issues were taken care of.

Try it out on your next project and let me know what you think. Ideas for improvement will be highly appreciated.

 

Filed Under: Collaboration, Experience from the Field, Project Management, Tools Tagged With: , , ,

Leadership Lessons from Xenophon’s Anabasis

August 12, 2011 By Alex Singh Leave a Comment

I just finished reading an old Greek classic, Anabasis, that I thoroughly enjoyed. The lessons on leadership are still valid today.

2400 years ago, Xenophon took the initiative to lead 10,000 stranded Greek mercenaries out of western Persia (modern day Turkey and Iraq). The Greeks were 1,100 miles from home and had to retreat through inhospitable deserts and snow-filled mountain passes to the security of the closest Greek cities on the Black Sea. Throughout the journey, they were blocked and constantly attacked by the numerically superior Persian army.

During their retreat, when some mercenaries were disheartened because the Greeks had no cavalry, Xenophon reminded them that: “Wars may be fought with weapons, but they are won by men.” He also said: “Ten thousand cavalry only amount to 10,000 men. No one has ever died in battle by being bitten or kicked by a horse; it is men who do whatever gets done in battle.”

This is true of any human undertaking — it is men and women who get the job done. This is true for software development too — it is people, not horses (tools), that win struggles. Resources count, but they are not the deciding factor — people are.

So if you are ever faced with a situation that is not going well, ask yourself if you (the leader):

  • Have the right people and more importantly if you are providing them the right leadership
  • Give team members what they need to get their work done and provide them opportunities to develop their skills.
  • Get out in front and set the example
  • Help and teach others whenever they need your help and are ready to accept it
  • Treat others with respect and give recognition for good work
  • Take care of your team members and put the project before self
  • Get your team thinking about the positive actions that they can take to succeed

If you don’t do any of these, it is doubtful if the team will trust or follow you; if you do, the team will always come through for you.

You can read the whole story about the Greek retreat in Xenophon’s “Anabasis” at http://ebooks.adelaide.edu.au/x/xenophon/x5an/ or on Project Gutenberg at http://www.gutenberg.org/catalog/world/readfile?fk_files=862407.

Filed Under: Leadership
« Older Posts