Jeff Patton, a.k.a Father of Agile-UX, is doing the most innovative work around product discovery, release planning, agile interaction design, and putting requirements into context. Jeff won the Gordon Pask Award in the year 2007, for his work helping establish what User-Centered Design means in Agile.

Jeff brings two decades of experience from a wide variety of products from on-line aircraft parts ordering to electronic medical records to help organizations improve the way they work. Where many development processes focus on delivery speed and efficiency, Jeff balances those concerns with the need for building products that deliver exceptional value and marketplace success.

We are thrilled to offer Jeff’s exceptional Passionate ProductOwner (CSPO) workshop at the Agile India 2013 Conference.

Recently, we caught up with Jeff and asked him the following questions:

Why the passion in product ownership?

First off, “Passionate Product Ownership” is a stupid title, because you can’t teach someone passion! However, I’ve always been involved in Product Development and Product Management, and I take the greatest pride from knowing that I’ve made a product or put something out into the world that other people use. The class focuses on understanding the business problems we are solving – the people who will use the product and understanding what their problems are. While I can’t teach passion, we can certainly focus on helping everyone understand that they are building products that help people, and that’s where the passion comes from.

The product ownership role is often defined as one of the most challenging roles defined in scrum, why is this?

Scrum and Agile processes in general, offer a lot of tactical guidance for how to get software built. But most Agile processes depends on getting the right person in the Product Ownership role – someone who already knows what to build.

This role difficult because you are responsible for building the right thing, and you are also responsible for communicating what that right thing is to a large group of people, sometimes in excruciating detail! In this class, one of the first things you’ll learn is that while there may be a single Product Owner who acts as a leader, product ownership is handled by a team of people. I’d rather that the role of Product Owner was named “Product Leader” and that whole teams take ownership. If you survive the class and adopt this way of thinking, you’ll be practicing a type of product ownership where everyone is involved in figuring out the details of what to do, who the user is, how best to help them and what solutions should be built and described in detail.

You’ve done significant work in blending UX & Agile. Where do you think the community is headed as far as UX on Agile projects go?

That’s a great question! It depends on which community you’re talking about. In the early 2000s, I spent a lot of time in the Agile community trying to help them understand what user experience was and its importance. Simultaneously, I spent time with User Experience people trying to help them not be so darn afraid of Agile Development as if it was going to “wreck” things.

I’ve seen a lot of maturation over the last decade and many UX people now have experience working inside Agile projects and teams. The coolest thing that’s happened within the User Experience community is that they have learned to change their practice so it works better in an Agile context. I’ve also seen more and more organizations working with Agile development recognizing the importance of understanding users and building products that people like. Organizations see that UX is the kind of work that happens outside the code and it isn’t an “engineering thing.” Currently, I am seeing the User Experience community going deeper and evolving practices that work better. For example, you’ll find books on Agile User Experience and Lean User Experience. Also more and more people who teach Agile practices acknowledge, or at least understand, what a user experience person does, although some challenges remain.

A new kind of Agile is forming, where the work that UX people do to understand users, prototype and try out ideas, is now called Lean Start-Up. A friend of mine, Leah Buley, once said, “Design isn’t a product that designers produce. Design is a process that designers facilitate.” The communities are starting to understand that the user experience work is cross-cutting and the concern is threading it’s way into everyone’s process.

What will be the key take away for the workshop attendees?

You will learn the practices that support the “Product Discovery” process and how to do discovery well. Building the right product is about understanding who the product is for and how they are going to benefit from using it. This is not a singular person’s responsibility – it is the whole team’s responsibility. The practices you’ll get in the class that support this come from user experience. Practices such as simple personas and story mapping provide understanding of users and model user behaviors. You’ll also get practices for good project management. For example, focusing product releases on specific target users, tactically guiding releases, ways to slice stories thinly to slowly build up a product, so that as soon as possible, it is a shippable, complete product. You’ll also gain practices for building small amounts of product as experiments to really validate if you are building the right product.

Limited seats are available for Jeff’s Product Ownership workshop. Book your seat today to avoid disappointment: http://booking.agilefaqs.com

Suppose we had the following (utterly) simplistic requirement:

@Test
public void politiciansDontNeedToPayTax() {
    whenIncomeIs(10000).verify(POLITICIANS).pay(0);
}
 
@Test
public void residingAliensGetAwayByPayingLittleTax() {
    whenIncomeIs(10000).verify(ALIENS).pay(1000);
}
 
@Test
public void richPeopleArePunishedWithHighestTax() {
    whenIncomeIs(10000).verify(RICH_PEOPLE).pay(3000);
}

where:

TaxPayer RICH_PEOPLE = new RichPeople();
TaxPayer ALIENS = new ResidingAliens();
TaxPayer POLITICIANS = new Politicians();

To fullfil this requirement, we’ve the following code:

Parent Class:

public abstract class TaxPayer {
    protected abstract double getTaxPercentage();
 
    public double calculateTaxAmount(final long income) {
        if (getTaxPercentage() == 0)
            return 0;
        return income * getTaxPercentage() / 100.0;
    }
}

Each child class:

public class Politicians extends TaxPayer {
    private double taxPercentage = 0;
 
    @Override
    protected double getTaxPercentage() {
        return taxPercentage;
    }
}

public class RichPeople extends TaxPayer {
    private final double taxPercentage = 30;
 
    @Override
    protected double getTaxPercentage() {
        return taxPercentage;
    }
}

public class ResidingAliens extends TaxPayer {
    private final double taxPercentage = 10;
 
    @Override
    protected double getTaxPercentage() {
        return taxPercentage;
    }
}

One would wonder what good are these child classes? Feels like a class explosion. Sure enough! This is the pathetic state of Object Oriented programming in many organizations, esp. the Enterprise software side of the world.

One could have easily used an enum to solve this problem:

public enum TaxPayer {
    Politicians(0), Aliens(.1), RichPeople(.3);
 
    private double taxPercentage;
 
    private TaxPayer(double taxPercentage) {
        this.taxPercentage = taxPercentage;
    }
 
    public double calculateTaxAmount(final long income) {
        return income * taxPercentage;
    }
}

Unfortunately many developers think they already know enough values and principles, so its not worth spending anytime learning or practicing them. Instead they want to learn the holy grail of software design – “the design patterns.”

While the developers might think, design patterns is the ultimate nirvana of designing, I would say, they really need to learn how to think in their paradigm plus internalize the values and principles first. I would suggest developers should focus on the basics for at least 6 months before going near patterns. Else they would gain a very superficial knowledge about the patterns, and won’t be able to appreciate its true value or applicability.

Any time I get a request for teaching OO design patterns, I insist that we start the workshop with a recap of the values and principles. Time and again, I find developers in the class agreeing that they are having a hard time thinking in Objects. Most developers are still very much programming in the procedural way. Trying to retrofit objects, but not really thinking in-terms of objects and responsibilities.

Recently a student in my class shared that:

I thought we were doing Object Oriented Programming, but clearly its a paradigm shift that we still need to make.

On the first day, I start the class with simple labs, in the first 4-5 labs, you can see the developers struggle to come up with a simple object-oriented solution for basic design problems. They end up with a very procedural solution:

• main class with a bunch of static methods or
• data holder classes with public accessors and other or/er classes pulling that data to do some logic.
• very heavy use of if-else or switch

Its sad that teams don’t understand nor give importance to the following important OO concepts:

• Data and Logic together – Encapsulation (Everyone knows the definition of encapsulation, but how to put it in proper use, is always a big question mark.) Many developers write public Getters/Setters or Accessors by default on their classes. And are shocked to realize that it breaks encapsulation.
• Inheritance is the last option: It is quite common to see solutions where slight variation in data is modeled as a hierarchy of classes. The child classes have no behavior in them and often leads to a class explosion.
• Composition over Inheritance – In various labs, developers go down the route of using Inheritance to reuse behavior instead of thinking of a composition based design. Sadly, inheritance based solutions have various flaws that the team can’t realize, until highlighted. Coming up with a good inheritance based design, when the parent is mutable, it extremely tricky.
• Focus on smart data-structure: The developers have a tough time coming up with smart data-structure and putting logic around it. Via various labs, I try to demonstrate how designing smart data-structures can make their code extremely simple and minimalistic.

I’ve often noticed that, when you give developers a problem, they start off by drawing a flow chart, data-flow diagram or some other diagram which naturally lends them into a procedural design.

Thinking in terms of Objects requires thinking of objects and responsibilities, not so much in terms of flow. Its extremely important to understand the problem, distill it down to the crux by eliminating noise and then building a solution in an incremental fashion. Many developers have a misconception that a good designs has to be fully flushed out before you start. I’ve usually found that a good design emerges in an incremental fashion.

Even though many developers know the definition of high-cohesion, low-coupling and conceptual integrity, when asked to give a software or non-software example, they have a hard time. It goes to show that they don’t really understand the concept in action.

Developers might have read the bookish definition of the various Design Principles. But when asked to find out what design principles were violated in a sample design, they are not able to articulate. Also often you find a lot of misconception about the various principles. For example, Single Responsibility, few developers say that each method should do only one thing and a class should only have one responsibility. What does that actually mean? It turns out that SRP has to do more with temporal symmetry and change. Grouping behavior together from a change point of view.

Even though most developers raise their hands when asked if they know code smells, they have a tough time identifying them or avoiding them in their design. Developers need a lot of hands-on practice to recognize and avoid various code smells. Once you learn to recognize code smells, the next step is to learn how to effectively refactor away from them.

Often I find developers have the most expensive and jazzy tools & IDEs, but when you watch them code, they use their IDEs just as a text-editor. No automated refactoring. Most developers type “Public class xxx” instead of writing the caller code first and then using the IDE to generate the required skeleton code for them. Use of keyboard shortcuts is as rare as seeing solar eclipse. Pretty much most developers practice what I call mouse driven programming. In my experience, better use of IDE and Refactoring tools can give developers at least 5x productivity boost.

I hardly remember meeting a developer who said they don’t know how to unit test. Yet time and again, most developers in my class struggle to write good unit tests. Due to lack of familiarity or lack of practice or stupid misconceptions, most developers skip writing any automated unit tests. Instead they use Sysout/Console.out or other debugging mechanism to validate their logic. Getting better at their unit testing skills and then gradually TDD can really give them a productivity boost and improve their code quality.

I would be extremely happy if every development shop, invested 1 hour each week to organize a refactoring fest, design fest or a coding dojo for their developers to practice and hone their design skills. One can attend as many trainings as they want, but unless they deliberately practice and apply these techniques on job, it will not help.

At the SDTConf, we had an interesting discussion on how to deal with technical debt. The group agreed on the following suggestions:

• C3: Coverage, Complexity & Churn – Instead of looking at each of these parameters in isolation, we generate C3 graph using a TreeMap and use the cumulative graph to see red spots in the product. Esp. helpful to quickly raise awareness.
  
• Slack: Every team members gets a 10-20% time every iteration to invest on things that hurt them.
• Scratch your Personal Itch day: Every iteration each team members gets 1 day to fix unplanned issues on the project
• Visitor from Hell: Every month have one person from other team visit you and give you feedback on various aspect of the team. Its up to the team to address these issues or not. But certainly can be used to pitch to the management for additional time to work on these issue.
• Code Walk Throughs: Every time a team member (or pair) implements something important, they give a code walk through or a demo to the rest of the team. This usually ensures team members don’t have crappy things when they give a demo.

Check out the project rescue report, if you would like to see some examples of how we’ve used C3.

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

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

Many people will argue that there is more badly written code than good code. And its important to write comments to avoid these situations. Therefore we should encourage (force) people to write comments.

IMHO they are absolutely right that today many project suffer from poorly written code without any (good) comments. However every team I know, that suffers from this problem, has always been told (forced) to write comments. In spite of the emphasis on writing comments it has not really helped them.

I usually ask:

By asking developers to write comments are we really addressing the root of the problem?

.i.e. developers don’t invest quality time to write self-documenting code; code that clearly communicates its intent and does not require the deodorant of comments.

May be its time to try something different?

I have seen this myself many times, when we emphasize & educate the team on how to write clean code and ask them to stop wasting time writing comments, the code starts to communicate lot better. Its lot more maintainable. Also we have found that writing automated tests is a great way to document your intent as well.

This is how I would explain the concept Comments Smell to a team:

Writing comments that explain “how” or “what” the code does, what it does, is evil IMHO. Comments (esp. about what and how) is a clear failure to express the intent in code. Comment is a deodorant to hide that failure (smell).

• If developers don’t invest time to write clear code, what is the guarantee that they will write clear comments?
• Is doing a mediocre job at both (comments and code) better than doing a great job at just Code?
• Will it actually be more productive to do both or just one?

Remember the biggest problem with comments it that they fall out-of-sync with code very soon. So its not just about the extra investment to write good comments, but also the investment to maintain them.

One has to think hard to write code that expresses intent rather than write some sloppy code with poor abstractions and get away (washing their hands off) by writing comments. Developers have to take responsibility for writing code that others can easily understand.

Having said that, there are times when “the why” (why we are doing something in the code, a particular way) is not apparent by just looking at the code. So if we don’t find a suitable way to communicate “the why” through code, comment is the fall back option.

Note that comments are a fall back option in “the why” case rather than a default option.

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:

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++;

Posted in Agile, agile india, Coaching, Interview Process, Training | No Comments »