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 ‘Training’ Category

Interview with Dean Leffingwell- Leading SAFe Workshop

Thursday, January 23rd, 2014

Enterprise solutions for Agile have always been a challenge for many organisations. Dean Leffingwell, software industry veteran and creator of Scaled Agile Framework (pronounced as SAFe) is running a workshop at Agile India 2014. This workshop will introduce the participants to the principles, values and practices of SAFe.

Dean Leffingwell

His deep rooted expertise and his pragmatic solutions to real time problems have resulted in successful enterprise level implementation of Agile across organisations. His hands-on approach and practical examples make him as one of the sort after expert in this domain.

Dean Leffingwell

He is also the founder and CEO of ProQuo- a consumer marketing identify company, and the author of Agile Software Requirements, Scaling Software Agility, and Managing Software Requirements.

Dean Leffingwell's Books

We had a short chat with him, where we discussed about SAFe and his experience with various kinds of organisations.

1. In your opinion, what is the biggest challenge companies are facing while scaling agile methods at their org. level?

Primarily, educating ALL the stakeholders to the new process, and bringing everyone to understand the benefits, and the changes necessary to achieve the new common, SAFe/ Lean|Agile way of working.

2. ‘Enterprise Agile’- Is it an oxymoron?

No. SAFe has been successfully applied to enterprises with hundreds, and even thousands, of practitioners.

3. There is a common misconception that Leadership has no role to play in Agile. What do you think is the role of leadership in implementing SAFe ?

In SAFe, Leadership is not excluded. Indeed, leaders assume the primary responsibility for successfully implementing the new way of working. Training is provided to help them on this new learning journey.

4. In your experience, is SAFe more suitable for Services or Product Company? Is there any difference?

No tangible differences. The principles and values of SAFe, and the underlying principles of product development flow, apply in both contexts.

5. Are there any gotchas that teams should be aware while implementing SAFe?

Any transformation of this scope is hard. If enterprises could have achieved the benefits via their old way of working, they would have already done so. Lean, Agile and Scaled Agile change most everything! But SAFe is powered by Agile, so the personal, team and business benefits are well worth the effort.

6. What is the key take away from your 1-Day SAFe workshop?

This workshop is a distillation of the popular two-day “Leading SAFe” course. While it lacks the depth that the two-day course provides, it covers all the foundational elements and is delivered by Dean Leffingwell, the creator of SAFe.

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2014#workshops

Interview with Dave Thomas – Advanced Ruby Workshop

Monday, January 20th, 2014

Dave Thomas is one of the keynote speakers at Agile India 2014. Many of you might know him  as one of the 17 original authors of the Agile Manifesto or the founder of Agile Alliance or the person who brought Ruby programming language to the western world or the co-author of The Pragmatic Programmer or the co-founder of Pragmatic Bookshelf.

Dave Thomas

Besides the keynote, Dave is also running a one-day workshop about the advanced features of Ruby 2.0.

Dave Thomas Books

We did a short interview with him to understand his views about Ruby and programming in general.

1. Tell us a little bit about your first introduction to Ruby? What was your reaction?

I am a programming language nut. I love trying new languages. Back in the 90’s, I’d download languages from Usenet (ask your parents) and play with them—normally several a week.

Back in 1997 or ’98 I downloaded Ruby. I think it was version 1.4.

Normally when I try a language, I stop after an hour or so. Very few are different enough to warrant the time. With Ruby, I was still playing hours later. At the end of the day, I called my business partner Andy Hunt and told him he should try it too.

And I’m still using it today.

2. How do you think Ruby has changed the way we program today?

I think Ruby has done several things.

First, the Ruby community has really lead the way with  testing. Andy and I were among the authors of the Agile Manifesto, and so we helped spread the word about Ruby among the early Agile crowd. In turn, those folks used Ruby to experiment with agile concepts. The result is that the Ruby world probably has more commitment to testing than any other language.

Second, I think Ruby has shown that dynamic languages can be used in the real world. In the early 2000’s, there was a lot of skepticism—sure these “scripting languages” were fun, but to write real programs, you needed grown-up languages with type checking.

Of course, these people were wrong. They were wrong firstly because, at least back then, Java, their language of choice, was effectively dynamically typed—the majority of runtime objects were help in collections, and were untyped in those collections.

And secondly, they were wrong because type checking, at least as they meant it, didn’t really catch the kinds of errors people actually made.

So I think Ruby has made a fundamental difference to the way we see programming today.

3. What are the advantages of Ruby over other programming language?

It makes people happy.

4. After reading your book, Pragmatic Programmer, it changed the way I thought of my career as a developer. Recently Chad wrote another book, Passionate Programmer. How is it different?

Thank you for the kind words.

The Pragmatic Programmer was largely about programming—our advice was aimed at helping developers become better programmers.

The Passionate Programmer is a truly great book because it takes a different, and in a way more important, tack. It is not about programming. It is about  programmers. Chad writes about how you, as a programmer, can become a better, more rounded, and happier individual. Yes, it will make you a better programmer. But mostly it will make you a better person.

I think everyone should read this book (even non-programmers).

5. With power comes responsibility- How do you think the Ruby community is utilising the power of this languages responsibly?

We touched a little on this when we talked about testing and agility. But let’s flesh it out.

Let’s start with “with great power comes great responsibility.” That (I think) is a quote from Spiderman – Peter Parker’s Uncle is giving him advice. And look how happy that makes our hero. He is weighed down by the burden.

So, while the quote may be true, I don’t necessarily believe it is a good thing.

In general, great power is a burden – people with power constantly need to be exercising it or they feel that they are wasting a gift. It is also a curse, because people become scared of losing that power, and as a result tend to stagnate rather than try risky things. It is true of people, and it is true of communities.

So I’m proud of the Ruby community for taking a middle road. In general, I think that are pretty responsible and mature (with certain glaring exceptions :). But I also think that they remember to have fun. They do take risks, they do explore, and they do exhibit whimsy.

6. Are you happy with how Ruby, as a language and as a community has evolved? Where would you like it go?

I think I answered the first part of this.

The second part – well, I don’t think I have a direct answer.

You see, I don’t think programming languages are special things. They don’t exist because someone came up with a syntax, or because someone published a book.

Programming languages are simply tools. They let developers like us solve problems. The better languages help us to feel good while we are doing it.

So we need to be careful to avoid the trap of becoming religious about one particular language. We need to have the breadth to choose tools that are appropriate to the task at hand. Ruby is a particular tool, with strengths and weaknesses.

Maybe you’re a carpenter. After many years of searching, you’ve found a great hammer. It fits your hand, it’s the right weight, it drives all kinds of nails. And then you come across a screw.

There are two reactions to this. One is to say “my hammer is a great tool. Let’s see if I can adapt it to drive screws, too.” Maybe you weld a blade to it, or maybe you grind a ridge into the top that fits the screw slot.

Or maybe you go out and find a screwdriver.

That’s how I feel about Ruby. It is a fantastic tool, and one I still use daily. But I don’t want it to become something where developers say “I am a Ruby programmer.” Instead, I want to hear “I am a programmer, and I use Ruby in many jobs because it means I can deliver stuff better.”

So, what do I want Ruby to become? Anything that helps people be better developers.

7. What is the key takeaway from your Advanced Ruby workshop?

Ruby often seems magic. That’s part of the fun. But, in reality, the magic comes from some simple but subtle underlying principles. Understand this, and you master Ruby. And that’s where the _real_ fun is.

This workshop has limited seats and only few are left. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2014#workshops

What is required for Deliberate or Deep Practice?

Wednesday, December 18th, 2013

There is an old saying that “Practice makes perfect“. But not all practice can make you perfect. There is a specific type of practice usually referred to as deliberate practice or deep practice which can really help you master the skill at hand.

Geoff Colvin, the author of the groundbreaking bestseller Talent Is Overrated explains that deliberate practice can be described by these five characteristics:

  1. It’s designed specifically to improve performance
  2. It can be repeated a lot
  3. Feedback on actions is continuously available
  4. It’s highly demanding mentally
  5. It isn’t much fun

Hence a short, focused and regular practice session is lot more effective than one long, generic, random practice session.

Its also important to note that deliberate/deep practice requires a certain context or mindset to really facilitate the learning. Following are important characteristics:

  • You are slightly off-balance, trying to get back
  • You are constantly getting tons of clear, instant feedback
  • You are at the edge of your ability, but motivated to stretch yourself a little bit more
  • You are staring at you role models, .i.e. you’ve a clear idea of your goals or the kind of person you want to become.

The advantage of deliberate practice is cumulative, hence starting early has a big advantage.

Generally, I used to be against rote learning, but now I’m rethinking through my conclusions.

If this topic interests you, I would strongly recommend the following books:

Some good videos to start on this topic:

Train-the-Trainer Model for scaling Training in your organization

Wednesday, August 14th, 2013

How do you effectively scale skill-based, quality training across your organization?

Over the years, I’ve experimented with different ideas/models to scaling skill-based training across an organization. In the last 4 years, I’ve pretty much settled down on the following model. Its very useful when mentoring teams on skills like Test-Drive-Development (TDD), Behavior-Driven Development (BDD), Product Discovery, Writing User Stories, Evolutionary Design, Design Patterns, Problem Solving, etc.  I’ve successfully implemented this model at some very prominent fortune 500 enterprises.

Train The Trainer Model

* This model assumes that the potential trainer has first-hand working experience on the subject to be trained on. Also we assume they have the basic skill required for effectively delivering any training. We are mostly focusing on building on those 2 basic skills to help them deepen their subject matter expertise and enable them to effectively impart their knowledge.

I curious to know what other models have worked for people and if anyone else has tried this model?

Passionate ProductOwner (CSPO) Workshops by Jeff Patton at Agile India 2013 Conference

Thursday, January 17th, 2013

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 Patton Story Mapping

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.

Jeff Patton

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

Goodbye Simplicity I’m Object Obsessed – Example

Saturday, July 14th, 2012

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:

Tax Payer

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:

Refactored Tax Payer

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

Stay away from Design Patterns; master Value, Principles and Basics Skills first

Thursday, June 7th, 2012

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.”

Values Principles and 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.

Ways to Deal with Technical Debt

Tuesday, May 1st, 2012

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.

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

 

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
    Licensed under
Creative Commons License