Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Archive for the ‘Coaching’ Category

“Investing in Innovation” is Absolutely Overrated!

Thursday, March 22nd, 2012

Invest today in Innovation to ensure you’ll thrive long-term. Else be prepared to get wiped out!

I’m sick and tired of hearing such lame advice from people.

I don’t know of any company where they were struggling. So they “invested” in “innovation” and suddenly started building great products.

It’s like saying:

30-mins of daily Meditation (alone) will make you more creative!

Sorry you need to practice your art to sharpen your creativity. Meditation can certainly help, but not the essential ingredient for creativity.

Important thing to note is, one cannot treat innovation as a separate thing in which they can “invest” to reap benefit downstream.

Thinking of innovation as an independent entity, separate from the work itself and the culture/context in which the work is done, is fundamentally wrong IMHO.

One has to experiment and try new approaches. You cannot do your work the same old way and set some time aside for innovation. I’ve not seen that work.

In my view of the world, innovation is part of how you think and operate. To some extent its the nature of people and organizations. Its part of your work and the culture of your organization. In fact, innovation is inherent aspect of many businesses. One cannot bring innovation from outside.  Hence one cannot invest in innovation.

“Invest in Innovation” is like saying “Invest in Learning.”

If you are not learning while doing your daily job and thinking of investing time outside your job to learn, then you are in trouble. Either develop the attitude to learn on the job or find a job where learning is inherent part of your job, not something you do in the side.

If you are learning on the job and want to invest additional time to pick up new skills that’s great. But learning on the job is a pre-requisite.

Innovative thinking should be an integral part of your job and your company’s culture, not something you invest after the fact.

Defining Process Success

Friday, March 2nd, 2012

Often companies ask me:

 ”How do we know if this process is successful? How do we measure if this process is working for us?”

I don’t think any process by itself can make someone successful. A lot depends on the company, its values, principles, nature of business, its people and so on.

If I wanted to introduce a new process into my company, this is what I would measure or look for:

  • Is it helping my product/organization? Things like
    • time to market,
    • frequency of releases,
    • perceived quality/stability of the product and so on.
    • Basically aspects about my product delivery which were good (want to continue doing them) and aspects which needs improvement.
  • Is the team evolving the process? Are they internalizing the process and reducing the amount of ceremony?
    • While the process should encourage people to do reflective improvement, it should also encourage some amount of disruptive changes thinking into the teams/company.
  • Is the process creating growth opportunities for my people?
    • I would like the process to encourage growth in terms of them becoming Generalizing specialists and not being corned into silos.
    • I want my people to improve their overall understanding and involvement in the overall product development process rather than just knowing or caring about their little piece.

Also Jeff Patton has a wonderful article on Performing a simple process health checkup:

He suggests we look for the following “properties” to assess the process’ health:

  1. Frequent delivery
  2. Reflective improvement
  3. Close communication
  4. Focus
  5. Personal safety
  6. Easy access to experts
  7. Strong technical environment
  8. Sunny day visibility
  9. Regular cadence

I would like to add 3 more properties to this list:

  1. High energy
  2. Empowered teams
  3. Disruptive change or Safe-Fail Experimenting

 

The Energy Project: Getting More Out of People by Demanding Less

Monday, January 2nd, 2012

A company called The Energy Project, are experts in the field of work performance and the problem of employee disengagement. They believed that burnout is one of its leading causes, and focused almost exclusively on helping individuals avoid burnouts by managing their energy, as opposed to their time. Time, after all, is finite. By contrast, you can expand your personal energy and also regularly renew it.

They believe that enduring organizational change is possible only if individuals alter their attitudes and behaviors first. But they’ve come to understand that it’s not possible to generate lasting cultural change without deeply involving the whole organization and its senior leadership.

To achieve better Productivity, they encouraged organizations to make two fundamental shifts in the way it manages employees:

  1. Stop expecting people to operate like computers—at high speeds, continuously, running multiple programs at the same time—and to recognize that human beings perform best and are most productive when they alternate between periods of intense focus and intermittent renewal.
  2. Move from trying to get more out of employees and instead to invest in systematically meeting their four core needs, so they’re fueled and inspired to bring more of themselves to work every day.

Four core needs are:

  1. Physical health: achieved through nutrition, sleep, daytime renewal, and exercise
  2. Emotional well-being: which grows out of feeling appreciated and valued
  3. Mental clarity: the ability to focus intensely, prioritize, and think creatively and
  4. Spiritual significance : which comes from the feeling of serving a mission beyond generating a profit.

Several companywide initiatives can help employees boost their energy in the four core areas. For example companies can subsidize healthy meals and a salad bar at their on-site restaurant that’s open to all employees. Hire a dietician on staff and employees can get free consultations. Build new, fully equipped gym and created a large open, grassy commons area where people can hang out and relax. To help employees recharge themselves on a spiritual level, companies can offers its employees paid time off each month to volunteer their services to nonprofits and organizes specific volunteer opportunities for them.

Original Article: The Productivity Paradox: How Sony Pictures Gets More Out of People by Demanding Less

Deliberate Practice: The Expressway to becoming an Expert

Monday, January 2nd, 2012

“Its God’s gift” or “S/he was born talented” or “S/He just lucky” is a common myth that undermines the relentless hard-work experts put to attain mastery in their respect work.

Benjamin Bloom, a pioneer who broke this myth found out that:

“All the superb performers, he investigated, had practiced intensively, had studied with devoted teachers, and had been supported enthusiastically by their families throughout their developing years.”

Later research, building on Bloom’s study revealed that the amount and quality of practice were key factors in the level of expertise people achieved.

Consistently and overwhelmingly, the evidence showed that:

“Experts are always made, not born.”

The journey to truly superior performance is neither for the faint hearted nor for the impatient. The development of genuine expertise requires struggle, sacrifice, and honest, often painful self-assessment. There are no shortcuts. It will take many years if not decades to achieve expertise, and you will need to invest that time wisely, by engaging in “deliberate” practice; practice that focuses on tasks beyond your current level of competence and comfort. You will need a well-informed coach not only to guide you through deliberate practice but also to help you learn how to coach yourself.

One study showed that psychotherapists with advanced degrees and decades of experience aren’t reliably more successful in their treatment of randomly assigned patients than novice therapists with just three months of training are. There are even examples of expertise seeming to decline with experience. The longer physicians have been out of training, for example, the less able they are to identify unusual diseases of the lungs or heart. Because they encounter these illnesses so rarely, doctors quickly forget their characteristic features and have difficulty diagnosing them.

Practice Deliberately: Not all practice makes you perfect. You need a particular kind of practice – “deliberate practice” – to develop expertise. When most people practice, they focus on the things they already know how to do. Deliberate practice is different. It entails considerable, specific, and sustained efforts to do something you can’t do well – or even at all.

Let’s imagine you are learning to play golf for the first time. In the early phases, you try to understand the basic strokes and focus on avoiding gross mistakes (like driving the ball into another player). You practice on the putting green, hit balls at a driving range, and play rounds with others who are most likely novices like you. In a surprisingly short time (perhaps 50 hours), you will develop better control and your game will improve. From then on, you will work on your skills by driving and putting more balls and engaging in more games, until your strokes become automatic: You’ll think less about each shot and play more from intuition. Your golf game now is a social outing, in which you occasionally concentrate on your shot. From this point on, additional time on the course will not substantially improve your performance, which may remain at the same level for decades.

Why does this happen?

You don’t improve because when you are playing a game, you get only a single chance to make a shot from any given location. You don’t get to figure out how you can correct mistakes. If you were allowed to take five to ten shots from the exact same location on the course, you would get more feedback on your technique and start to adjust your playing style to improve your control. In fact, professionals often take multiple shots from the same location when they train and when they check out a course before a tournament.

Computer gaming is an excellent example where I’ve seen people practice deliberately to get better. They focus on what they can do well, but they also focus on what they can’t do well. Most importantly, when practicing, the gamer is not just mindlessly playing. It’s a very thoughtful, deep, dedicated practice session.

War games serve a similar training function at military academies. So do flight simulators for pilots. Unfortunately in software development, very few people practice deliberately.

Genuine experts not only practice deliberately but also think deliberately. The golfer Ben Hogan once explained, “While I am practicing I am also trying to develop my powers of concentration. I never just walk up and hit the ball.”

Deliberate practice involves two kinds of learning:

  1. Improving the skills you already have
  2. Extending the reach and range of your skills.

“Practice puts brains in your muscles” – Golf champion Sam Snead

The enormous concentration required undertaking these twin tasks limits the amount of time you can spend doing them.

How long should you do deliberate practice each day?

“It really doesn’t matter how long. If you practice with your fingers, no amount is enough. If you practice with your head, two hours is plenty.”

It’s very easy to neglect deliberate practice. Experts who reach a high level of performance often find themselves responding automatically to specific situations and may come to rely exclusively on their intuition. This leads to difficulties when they deal with atypical or rare cases, because they’ve lost the ability to analyze a situation and work through the right response. Experts may not recognize this creeping intuition bias, of course, because there is no penalty until they encounter a situation in which a habitual response fails and maybe even causes damage.

Many research show the importance of a coach/mentor in deliberate practice. Some strongly favor an apprenticeship model. However one needs to be aware of the limitation of just following a coach or working alongside an “expert.”

Statistics show that radiologists correctly diagnose breast cancer from X-rays about 70% of the time. Typically, young radiologists learn the skill of interpreting X-rays by working alongside an “expert.” So it’s hardly surprising that the success rate has stuck at 70% for a long time. Imagine how much better radiology might get if radiologists practiced instead by making diagnostic judgments using X-rays in a library of old verified cases, where they could immediately determine their accuracy.

All an all, “Living in a cave does not make you a geologist” .i.e. without deliberate practice you go no where.

Original Article: The Making of an Expert

Product Discovery Workshop – Agile India 2012 Accepted Proposal

Tuesday, November 1st, 2011

Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?

Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.

During this workshop, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

This day long workshop teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.

Detailed Activity Breakup

  1. PART 1: UNDERSTAND PRODUCT CONTEXT
    • Introduction
    • Define Product Vision
    • Identify Users That Matter
    • Create User Personas
    • Define User Goals
    • A Day-In-Life Of Each Persona
  2. PART 2: BUILD INITIAL STORY MAP FROM ACTIVITY MODEL
    • Prioritize Personas
    • Break Down Activities And Tasks From User Goals
    • Lay Out Goals Activities And Tasks
    • Walk Through And Refine Activity Model
  3. PART 3: CREATE FIRST-CUT PRODUCT ROAD MAP
    • Prioritize High Level Tasks
    • Define Themes
    • Refine Tasks
    • Define Minimum Viable Product
    • Identify Internal And External Release Milestones
  4. PART 4: WRITE USER STORIES FOR THE FIRST RELEASE
    • Define User Task Level Acceptance Criteria
    • Break Down User Tasks To User Stories Based On Acceptance Criteria
    • Refine Acceptance Criteria For Each Story
    • Find Ways To Further Thin-Slice User Stories
    • Capture Assumptions And Non-Functional Requirements
  5. PART 5: REFINE FIRST INTERNAL RELEASE BASED ON ESTIMATES
    • Define Relative Size Of User Stories
    • Refine Internal Release Milestones For First-Release Based On Estimates
    • Define Goals For Each Release
    • Refine Product And Project Risks
    • Present And Commit To The Plan
  6. PART 6: RETROSPECTIVE
    • Each part will take roughly 30 mins.

I’ve facilitated this workshop for many organizations (small-startups to large enterprises.)

More details: Product Discovery Workshop from Industrial Logic

Techniques

Focused Break-Out Sessions, Group Activities, Interactive Dialogues, Presentations, Heated Debates/Discussions and Some Fun Games

Target Audience

  • Product Owner
  • Release/Project Manager
  • Subject Matter Expert, Domain Expert, or Business Analyst
  • User Experience team
  • Architect/Tech Lead
  • Core Development Team (including developers, testers, DBAs, etc.)

This tutorial can take max 30 people. (3 teams of 10 people each.)

Workshop Prerequisites

Required: working knowledge of Agile (iterative and incremental software delivery models) Required: working knowledge of personas, users stories, backlogs, acceptance criteria, etc.

Testimonials

“I come away from this workshop having learned a great deal about the process and equally about many strategies and nuances of facilitating it. Invaluable!

Naresh Jain clearly has extensive experience with the Product Discovery Workshop. He conveyed the principles and practices underlying the process very well, with examples from past experience and application to the actual project addressed in the workshop. His ability to quickly relate to the project and team members, and to focus on the specific details for the decomposition of this project at the various levels (goals/roles, activities, tasks), is remarkable and a good example for those learning to facilitate the workshop.

Key take-aways for me include the technique of acceptance criteria driven decomposition, and the point that it is useful to map existing software to provide a baseline framework for future additions.”

Doug Brophy, Agile Expert, GE Energy

Learning outcomes

  • Understand the thought process and steps involved during a typical product discovery and release planning session
  • Using various User-Centered Design techniques, learn how to create a User Story Map to help you visualize your product
  • Understand various prioritization techniques that work at the Business-Goal and User-Persona Level
  • Learn how to decompose User Activities into User Tasks and then into User Stories
  • Apply an Acceptance Criteria-Driven Discovery approach to flush out thin slices of functionality that cut across the system
  • Identify various techniques to narrow the scope of your releases, without reducing the value delivered to the users
  • Improve confidence and collaboration between the business and engineering teams
  • Practice key techniques to work in short cycles to get rapid feedback and reduce risk

Introducing Churn

Saturday, October 22nd, 2011

How to destroy a team by introducing various forms of churn?

  • Have the Product Management change high-level vision and priority frequently.
  • Stop the teams from collaborating with other teams, Architects and important stakeholders.
  • Make sure testing and integration is done late in the cycle.
  • As soon as a team member gains enough experience on the team move him/her out of the team to play other roles.
  • In critical areas of the system, force the team to produce a poor implementation.
  • Structure the teams architecturally to ensure there is heavy inter-dependencies between them.
  • Very closely monitor team’s commitment and ensure they feel embarrassed for estimating wrongly.
  • Ensure the first 15-30 mins of every meeting is spent on useless talk, before getting to the crux of the matter.
  • Measure Churn and put clear process in place to minimize churn ;)

Hiring XP/Lean Coaches @ Industrial Logic, India

Wednesday, April 6th, 2011

Industrial Logic was founded in 1996, is headquartered in Silicon Valley and has a workforce distributed around the world.

We are a globally recognized Agile coaching, training and eLearning company, composed of internationally recognized Extreme Programming and Lean Management pioneers and practitioners.

Our mission is simple:

We inspire software teams to go from good to great.

Since the late 1990s, we’ve steadily improved the agility of ourselves and our global clients, including:

Standard Life HP Google GE ThoughtWorks

Our coaches are skilled practitioners who provide technical, managerial and entrepreneurial wisdom in their work with executives, managers, customers, analysts, developers, testers, internal-coaches and others.

Coaching for us means helping software people and organizations move towards high discipline, better risk management, reduced technical debt, increased productivity and delighted customers.

We judge our coaching engagements by whether we helped engender a culture of continuous improvement.

We teach live workshops and provide innovative Agile eLearning to help thousands of people around the world learn and practice valuable skills in Extreme Programming and Lean Management.

We begin most engagements with assessments that help groups understand current strengths and challenges, consider where they’d like to be tomorrow and map out strategies for getting there.

We are growing and we’re searching for highly-motivated XP/Lean coaches to join our company.

Interested? We currently seek ‘senior’ and ‘junior’ coaches. We expect our seniors to drop right into (paired) coaching immediately. The juniors, on the other hand, will need training and practice, and can expect their initial time to involve shadow-coaching with one or more seniors.

We are currently seeking coaches in India. We have domestic and international clients. Our travel schedules are manageable and balanced with local work. When not helping clients you’ll be contributing to the larger Agile community and collaborating with us on product development.

SENIOR XP COACH

  • A passion for excellence;
  • Ability to hit the ground running;
  • Coach organizations at different levels (Executives, Middle Management, Teams)
  • Outstanding communication skills, whether to geeks, suits, or anyone in between;
  • A willingness to travel approximately 30%-40% per year, generally working four-day weeks onsite every other week (often paired with another IL coach).
  • High energy and good cheer. A sense of humor is a big plus.
  • Willing to pick up new skills on their own at a very short notice
  • 4+ years of solid experience working on XP projects
  • 7+ years of software development, with specialty in Java, CSharp, and/or C++;

JUNIOR XP COACH

  • A passion for excellence;
  • Coach organizations at team level
  • Outstanding communication skills
  • Basic familiarity and some experience with the XP practices;
  • A willingness to travel approximately 30%-40% per year, generally working four-day weeks onsite every other week (often paired with another IL coach).
  • High energy and good cheer. A sense of humor is a big plus.
  • Willing to pick up new skills with limited guidance from others
  • 2+ years of solid experience working on XP projects
  • 3+ years of software development, with specialty in Java, CSharp, and/or C++;

At Industrial Logic, we eat our own dog food: when not at clients, we spend our own time developing products using an ultra-Lean process that we continually improve.

We emphasize sustainable pace, non-stop collaboration, and an overall tone of joyful camaraderie. It’s state-of-the-art agility around here.

Are we a match? If you think so, please send the following to jobs AT industriallogic DOT com

  • a subject line that reads “SENIOR COACH” or “JUNIOR COACH”
  • your resume
  • a brief statement on why you’d like to join our company
  • a sample piece of writing, such as an article, blog entry, etc.
  • links to communities or open source projects to which you’ve contributed

Our sincere thanks for your time and interest in Industrial Logic. We look forward to hearing from you!

Fundamental Attribution Error: Management/Coaches/Consultants Watch-out

Friday, January 21st, 2011

The fundamental attribution error (AKA correspondence bias/attribution effect) describes the tendency to over-value dispositional or personality-based explanations for the observed behaviors of others while under-valuing situational explanations for those behaviors.

For example, if Alice saw Bob trip over a rock and fall, Alice might consider Bob to be clumsy or careless (dispositional). If Alice later tripped over the same rock herself, she would be more likely to blame the placement of the rock (situational).

(Shameless rip-off from Wikipedia)

The funny part is, this error only occurs when we observe other’s behavior. We rarely apply fundamental attribution error to ourselves.

All of us are victims to this behavior daily. As Management, Coaches or Consultants, we need to be extra careful. Its easy to judge a team/company based on our personal explanation for the observed behavior and ignore the situational explanation.

For example, if a team of developers don’t meet their estimates, we might conclude that the developers are inexperienced and have not spent enough time estimating. They need to spend more time estimating, to get better at it. But if we look at the situational explanations, the developers don’t really understand what needs to be built, the person requesting for the feature is not clear what they expect, there might be a huge variety of ways in which the problem could be solved and so on. If we switch roles and try to play the developer’s role, we might be able to understand the situational/contextual explanation for the observed behavior.

I also see many people attribute poor team/company performance to lack of “Agile process”. They bring in the trainers and the coaches, who train and coach the team with standard “Agile practices”. Months/Years later, the team (what ever is left) have got good with process, but the product does not pull its weight and eventually dies out.

Fundamental Attribution Error is another reason why we see such vast spread abuse of Metrics in every field.

So how do we deal with this?

And I hear the Lean Extremists scream, 5 Whys5 Whys

Based on my personal experience, 5 Whys can also suffers from the same problem of Fundamental Attribution Error.

Being aware of the fundamental attribution error and other concepts like actor–observer bias and other forms of bias can help.

And in some cases, trial and error (brute force) seems to be the only answer.

User Story Mapping – Jeff Patton

Saturday, July 10th, 2010

A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.

Getting Ready to Produce

Saturday, July 10th, 2010

How do you know you are ready to start iterating? In some cases, very little is needed before the first iteration. In other cases, rushing to iterate (because you were told to) can lead to weeks of time wasted overly focused on delivering a poorly understood product.

In this presentation by David Hussman titled Getting Ready to Produce at Agile Mumbai 2010 Conference, David provides concrete tools for discovering your product context and assessing whether you are ready to start building and / or iterating. Participants learned tools for defining how much process you need and tools for truly understanding what you are building and why, as well as who will use it, why they will (or will not) use it and why.

    Licensed under
Creative Commons License