schedule 01:30 PM - 03:00 PM place Grand Ballroom 1

In order to achieve my goals, as a buyer of your product, I want awesome feature.

AT: make sure your users stories don't get in the way.

Users Stories, the tool teams use to break big ideas into small demonstrable deliverable, are easy to describe and challenging to write effectively. In this hands-on workshop you'll learn how to write great user stories that adhere to the INVEST principle. We'll learn various techniques to slice your stories using the vertical-slicing approach. We will discuss what elements should be included in the stories, what criteria you should keep in mind while slicing stories; why the size of your user story is important and how to make them smaller and efficient.

 
17 favorite thumb_down thumb_up 10 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Quick overview of Stories and Slicing Metaphor - 5 mins
  • What do you do to Large Stories? Spike, Split, Stub & Timebox (SSST) technique. - 5mins
  • Acceptance Criteria - 10 mins
  • Core Slicing Techniques: - 60 mins
    1. System Slice
      1.a. Static vs. Dynamic
      1.b. Real-time vs. Batch Processing
      1.c. Build vs. Buy
      1.d. Automated vs. Manual Steps
      1.e. Defer certain roles
    2. Behavioural Slice
      2.a. Adjusting Sophistication - MVF (Minimum Viable Feature) or Walking Skeleton
      2.a.1. Acceptance Criteria
      2.b. By-pass certain steps in the workflow
      2.c. Focus on Happy Path First (edge cases later)
      2.d. No options - 1 option - Many options
    3. Incrementally improve ‘Ilities' (Usability, Scalability, Reliability, etc.)
      3.a. Simpler UI (even consider using a standard UI)
      3.b. Minmal Data
      3.c. Improve Performance Iteratively
  • Product Discovery and Story Mapping - 10 mins

Learning Outcome

How to slice user stories.

Target Audience

Product Owners, Product Managers, Agile Coaches, Team Leads, Scrum Masters, Developers, Testers

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Vivek Ganesan
    By Vivek Ganesan  ~  1 year ago
    reply Reply

    Great! I have already added this session to my "To-Attend" list :)

  • Nayan Naidu
    By Nayan Naidu  ~  2 years ago
    reply Reply

    Hey Naresh,

    Great topic and of very much importance for having the expectations set in regards to the Stories, especially when both the team and PO are working together for the first time.

    One input though. I see that the session that you handled in the video shared, the session goes on for 2 hours. Here you have mentioned the session is planned to be for 90 minutes. Looking at the topics that are being covered, as you say in your video, condensing the content worth of 8 hours into 90 minutes seems to be tricky. May be you want to cut down the content to suite 90 minutes by may be focussing on a specific method? 

    Cheers,

    Nayan

    • Naresh Jain
      By Naresh Jain  ~  2 years ago
      reply Reply

      Thanks Nayan. Yes I plan to certainly reduce time on certain topics. But I would prefer doing that based on participants who show up for the workshop.

  • Naveen Kumar Singh
    By Naveen Kumar Singh  ~  2 years ago
    reply Reply

    Naresh, Interesting topic and looking forward to learn through this session about story slicing.

    Naveen 

  • Prasad
    By Prasad  ~  2 years ago
    reply Reply

    Naresh,

    Interesting topic, makes lot meaning for custom application development. Will you be covering any context of 'Packaged application', how stories can be sliced for customization, configuration and rollouts etc..

    ~~PP

    • Naresh Jain
      By Naresh Jain  ~  2 years ago
      reply Reply

      Thanks Prasad. Packaged application is an interesting area, when it comes to slicing user stories. I've some experience in applying the splitting techniques in those areas. If the participants are really interested, I can certainly share one or two relevant examples.

  • Jerry Rajamoney
    By Jerry Rajamoney  ~  2 years ago
    reply Reply

    Naresh,

    Thanks for this topic which is frequently asked by may PO's. On the lighter note I have the following query:

    You have mentioned many technique in the list. Any specfic reason for leaving out "Conversation and communication between team and PO". :)

    I found in few cases just the discussion between these two parties helps to break the stories.

    • Naresh Jain
      By Naresh Jain  ~  2 years ago
      reply Reply

      Thanks for the feedback Jerry. I've assumed conversation, communication and collaboration between PO and Team as a pre-req. Without that this topis is useless.

  • Joel Tosi
    By Joel Tosi  ~  2 years ago
    reply Reply

    Hi Naresh,

        I dig the session.  Help me understand what exercises the attendees would actually be doing?  Looking at the slides it appears that attendees aren't doing any exercises so much as you are facilitating a discussion and asking them which techniques were used, etc.  Am I reading that correct and is that your intent?

     

    Best,

    Joel

    • Naresh Jain
      By Naresh Jain  ~  2 years ago
      reply Reply

      Hi Joel, Thanks for your feedback. If you see the video, you'll see that the attendees are doing multiple excercises:

      • Trying to write stories from the flow chart and they run into the challenge of large stories
      • Second exercise is to use acceptance critiera to slice stories for profile uplaod
      • Post that there are 2 more exercises where they are given a screen and they have to slice stories from it.

      So basically they do 4 exercises and rest of it discussions. In a 90 mins tutorial, this is the best I can do.

      Hope this helps. Thanks again.


  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

    One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user's needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

    How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

    Most software organizations today suffer from what I call, the "Inverted Testing Pyramid" problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

    This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

    In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.

  • Liked Naresh Jain
    keyboard_arrow_down

    Naresh Jain - IAmA (I Am A ... Ask Me Anything)

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 2 years ago
    Sold Out!
    60 mins
    Keynote
    Beginner

    On Reddit, IAmA stands for "I am a" and AMA stands for "ask me anything".

    In an IAmA post, a person will post what they are, and other people will ask the original poster some questions to gain insights about the experience the person has had.
     
    Ex: I'm Jeff Patton, creator of Story Mapping, Ask Me Anything... OR I'm Diana Larsen, co-creator of the Fluency Model and co-author of Agile Retrospectives, Ask Me Anything...

    We plan to take this concept and apply it to the Agile context. We've few luminaries at the conference and we plan to do an live interview with them using this format.

  • Liked Anton Zotin
    keyboard_arrow_down

    Anton Zotin - Kanban Simulation with LEGO

    Anton Zotin
    Anton Zotin
    Agile Coach
    HERE, a Nokia company
    schedule 2 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    This workshop will help participants to understand how the Kanban method really works.

    We will learn how to use the Kanban method to visualize your current process ("start where you are"). Will figure out how to limit work in progress (WiP); define and make process policies explicit; measure and manage flow.

    Also we will figure out what does it mean to search for opportunities for continuous improvement. We will learn how to increase your team speed and at the same time decrease pressure at work.

    All of these we will touch through extremely hands-on step-by-step simulation using LEGO bricks.

     

  • 90 mins
    Workshop
    Beginner

    "To know, is good. To live, is better. To be, that is perfect." - The Mother

    During the Agile adoption, its a common complain that many team in many organizations get caught up in the ceremonies or mechanics of Agile and fail to understand/appreciate the true value and spirit of Agile. And because of this, the original intent of the Agile movement itself is lost. This is a serious issue!

    This workshop will highlight, a well-proven approach to transformation (not adoption) and show the distinct steps in this journey that an individual or a collective goes through when learning anything new. Activities, serving as examples, in the workshop, will focus to show the journey - that is, how to begin with rituals, then gradually move to practices, arriving at principles and eventually internalizing the values. Witnessing this gradual process of transformation will help participants discover for themselves their current progression. We hope this will serve as a guiding light during their Agile journey.

    Finally, we will leave the participants to ponder upon and discover for themselves their ideals in life and work as this is not only applicable to software development, but also to any discipline where humans are involved, including life itself.

  • Liked Ravi Kumar
    keyboard_arrow_down

    Ravi Kumar - Attaining Agile Fluency: Coaching Techniques - Focus on Goals Over Process

    Ravi Kumar
    Ravi Kumar
    Agile Coach
    AgileFAQs Tech
    schedule 2 years ago
    Sold Out!
    60 mins
    Experience Report
    Advanced

    What is coaching?

    “It is helping to identify the skills and capabilities that are within the person, and enabling them to use them to the best of their ability” — wikipedia

    "Individuals and Interactions over Process and Tools"

    The above is first of the 4 values espoused in the manifesto but yet it is common to see many agile coaches engage with teams and organisations advocating more and more processes. This is a common sight with new teams and also with teams on the path of agile transition from few months to few years irrespective of the competency, skills and maturity of the teams. Agile Fluency model created by Diana Larse and James Shore highlights the focus on value over compliance and practices at any given level

    “ Team fluency depends on more than just the capability of the individuals on the team. It also depends on management structures, relationships, organizational culture, and more. Don’t make the mistake of blaming individuals for low team fluency, or assuming that one highly-skilled individual will guarantee high team fluency ”

    An agile coach responsible for building high performing teams will need right set of powerful tools and techniques to leverage while working with teams and also to set the right expectations to both management and teams. This talk will draw from experience using few such powerful tools mentioned below while coaching teams attain fluency.

    1. Deliberate Practice
    2. Driving Empowerment & Self Organisation: Working Agreements
    3. Scaling Agile Transformation: Creating a Learning Org 
    4. Driving Commitment: Key Measures Highlighting Self Organisation

    This is not a beginner level talk and assumes participants having experience in leading agile teams and transformation initiatives in your respective organisations.

  • Liked Naresh Jain
    keyboard_arrow_down

    Naresh Jain - Sell Before you Build (MVP Hacks)

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 2 years ago
    Sold Out!
    60 mins
    Case Study
    Intermediate

    Before you write any code, make sure you have a failing test." This was a revolutionary idea, when it was first pitched in the late 90’s. Many successful entrepreneurs have been practicing a similar approach - "Before you build a product/service, make sure you have paying customers." In this talk, Naresh Jain shares his approach of finding effective MVPs to validate his Educational Product and why Agile Methods simply fail to do so. If you are interested in finding out how to maximise your validated learning for minimum investment, then this session is for you. Recently Naresh's article on this topic was published by InfoQ.

  • Liked Ankur Sambhar
    keyboard_arrow_down

    Ankur Sambhar - Promiscuous Pairing - More the merrier !!!

    Ankur Sambhar
    Ankur Sambhar
    Vice President
    J P Morgan
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    Being Agile developer, have tried & tested various flavors of pair programming over the years while working in highly motivated self-managed team. Some experiments worked while some worked better :)

    This talk is about sharing the personal experience of practicing promiscuous pairing which allowed the team to be always in the beginner's mind state and being able to push the boundaries consistently.

    This experience sharing talk is based on our successful adoption of the promiscuous pairing technique based on very famous research paper by Arlo Belshee "Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience".

  • Liked Prasad Kunte
    keyboard_arrow_down

    Prasad Kunte - Implementing Agile Engineering Practices in Legacy Codebases

    45 mins
    Case Study
    Intermediate

    Afraid of legacy code? Don't be!!!

    Most successful product companies are confronted with the problem of legacy code.

    What is a legacy code?

    • A code which is in production for several years.
    • A super-complex, hard to understand code base, written by different set of developers. 
    • Outdated Technology stack.

    But the most hurting reality is:

    Lack of confidence in the code due to zero or poor test coverage.

    Due to this reality, developers are often scared to touch it. They have very little confidence that "their code change wouldn't break the existing application in production."

    Recently at IDeaS, we came across such situation, where we needed to enhance one of our products containing legacy code. We started looking into the code and soon figured out that it was developed in 2007, hardly ever touched (& still working in production :)). The original team, which has worked on this product, could not be traced anymore.

    As this product has expanded to attract new customers, we had to change it significantly in order to support new customer's specifications. We had to make sure that the product was backward compatible and supported the earlier specifications, while we enhance the new specification.

    One simple option was to COPY PASTE every single method which needs to be modified and use an if-statement to decide which method to call. This certainly seems like an easy method, since the chances of breaking existing code is very little. 

    Today we all know this is a BAD option!!!

    Instead, our team decided to refactor the existing code to support plug-and-play approach for different specification. But before we started refactoring code, we had to build a safety net of tests around the existing code.

    How do we put the safety net? Ideal way would be to implement the Test Pyramid first. But, that would have taken significant time to be ready with the pyramid before we start touching the legacy code. And obvious, we would have missed the business goals.

    What do we do?

    Instead of building the entire test pyramid, we decided to attack different layers of the test pyramid, one at a time. Along the way, we followed the following approach:

    1. Re-structuring the Project code-base
    2. Establishing a baseline database: After taking a dump from the production database, we cleared out surplus data from the DB and setup a seed database with automed scripts
    3. Creating/fixing the build script 
      1. Setting up an auto DB deploy tool and integrating it with build scripts
    4. Set up basic CI pipeline
    5. Write a few work-flow tests to capture the system's flow from user's point of view
      1. Find the inception point in the code from where we can exercise the code
      2. Restify the application at the inception point (one service at a time)
      3. Setup authorization for production and test environment
      4. Build minimal test-data set for different environment 
      5. Create a few work-flow tests via the inception point (Test itself should not be coupled with the underlying database or implementation level components)
    6. Write business logic acceptance test to capture various complicated business rules
    7. Test drive the new enhancement or bug fixes
    8. Every time we touch legacy code, refactor the code and improve test coverage at unit level

    This really helped us test driven the new code and implement all the layers of the test pyramid.

    If you've a similar situation, join us, as we share our experience on how to confront legacy code.

  • Liked Jeff Lopez-Stuit, CEC
    keyboard_arrow_down

    Jeff Lopez-Stuit, CEC - Exploit Core Agile Practices at the Program Level

    45 mins
    Workshop
    Intermediate

    Core Agile practices establish visibility, remove impediments, and promote collaboration at the team level. Standup meetings, physical task boards, and focus on clearing impediments are well known practices to keep a team focused on the work, and establish a sense of flow towards frequent, tangible, and sustainable results.

    What about an entire program, when a large number of teams are involved? How can a large organization exploit the same core practices when there is highly interdependent work, and when there may be hundreds of people involved? How can Scrum be used to improve delivery times, increase quality, and promote sustainable development at a program level? How the can practices provide executive leadership the visibility they need into program progress?

    This workshop will introduce valuable, proven Scrum practices for large programs. Among the topics that will be discussed are:

    • What program management challenges are ripe for improvement through Agile practices?

    • The Program Impediment Board: Visible impediments, dependencies and milestones at a program level

    • The Program Stand-up: Lightweight activities to promote visibility, clear impediments and collaboration across the program

    • What does it look like when it’s working?: Improve delivery time, increase quality, and establish collaboration across the organization.

  • Liked Sophie Freiermuth
    keyboard_arrow_down

    Sophie Freiermuth - Integrating UX into the Agile Development Cycle - A case study over 3 projects

    45 mins
    Case Study
    Beginner

    User Experience design is a product design discipline which sits throughout a product's lifecycle, from inception to development to maintenance and all the way to retirement. Waterfall enabled the discipline to have ample time and produce extensive design, in a "big design upfront" approach which rarely involved technical capabilities, and resulted in difficulties in build. The adoption of agile by product development team has offered UX a unique opportunity to work in a much more joined-up manner, and expend the design into the development, enabling the entire team to react to change.

    As a UX designer, I have over the last 7 years developped a solid appreciation of working embedded in an agile development team, and would like to share my experiences through 3 specific projects, sharing my learnings to help development team on-board the UX practitioner, their tools, practices and skills.

    This session will be a case study over 3 projects, highlighting the learnings and steps of the integration of UX into the development cycle. I'm taking Alistair Cockburn's sequence of SHU-HA-RI to detail the progress of my practice and will pay great attention to sharing sufficient context that my experiences and outcomes can be translated to your own projects and team setups.

  • 60 mins
    Case Study
    Intermediate

    Adopting agile development practices and continuous delivery is becoming a norm in the software industry. Time to market and frequent releases have drastically reduced time available for regression testing. Inspection is considered wasteful. Faster feedback cycles during development is crucial. These have created lot of challenges for testing community, which traditionally relies on manual testing assisted by UI based test automation.

    This is an experience report of transforming testing practices across organization, which decided to embrace Agile. Today our testers are not trying to find defects, instead they collaborate with product management and developers to prevent them in the first place. In fact, during the appraisal process, the defects found by them is ignored, instead we focus on how much time they are able to dedicate to collaboration and exploratory testing. The boundaries between developers and testers have faded away and today quality is whole team's responsibility.

    We started with less than 20% of our testers with automation skills (mostly UI automation) and rest of them relying on manual testing. However, today, all our testers practice BDD. They have picked up Java & Groovy programming skills. They are able to contribute Workflow tests, Integration tests and Business Logic Acceptance Tests. Early collaboration and pairing is the norm. By the time developers are done with their tasks, all checks are already automated and hence we are able to deploy software every fortnight to production.

    Are your testers finding it hard to make this transition to an Agile mindset? This session will give you some concrete ideas based on our transition at IDeaS.  

  • Liked Yuval Yeret
    keyboard_arrow_down

    Yuval Yeret - Understanding and Implementing DevOps Flow

    Yuval Yeret
    Yuval Yeret
    Enterprise Agile Coach and CTO
    AgileSparks
    schedule 2 years ago
    Sold Out!
    480 mins
    Workshop
    Intermediate

    DevOps seeks to extend the agile benefits of Flow, Collaboration, Inspect and Adapt thinking all the way to Production. While DevOps and Continuous Delivery were born in the world of web operations in companies like Etsy, Google, Amazon, Facebook and Flickr (also called Unicorns in the DevOps community) it is now clear that Enterprise IT/Product Development companies (also known as Horses) can  also benefit immensely from the ideas and practices and achieve similar results if they manage the change/journey towards DevOps in a way that makes sense in their context. In this workshop we will introduce the concepts of DevOps and Continuous Delivery and help attendees figure out how DevOps can fit into their world as well as how a “DevOps Implementation” might look like.

  • Liked Ashish Parkhi
    keyboard_arrow_down

    Ashish Parkhi - Techniques to Speed Up your Build Pipeline for Faster Feedback.

    45 mins
    Experience Report
    Intermediate

    We would like to share our experience and journey on how we brought down our Jenkins build pipeline time down from over 90 minutes to under 12 minutes. In the process, we would share specific techniques which helped and also some, which logically made sense, but actually did not help. If your team is trying to optimize their build times, then this session might give you some ideas on how to approach the problem.

    Development Impact - For one of our build job, below graph shows how the number of builds in a day have increased over a period of time as the build time has reduced. Frequency of code check-in has increased; Wait time has reduced; failed test case faster to isolate and fix.

    Business Impact - More builds leading to quicker feedback and faster story acceptance and less story spill over.

  • 45 mins
    Talk
    Advanced

    Good engineering practices and fail-fast, iterative, low-ceremony processes help achieve team level agility. They are necessary but not sufficient to scale agility across the IT organization. In this talk, I'll address what else is needed and why. In particular, I'll address:

    1. Why plan-driven IT projects are a bad idea why we need value-driven projects instead
    2. Why a matrix org is a bad idea for IT and why we need cross-functional teams instead
    3. Why IT budgeting needs to change from being project-based to being team-capacity based
  • Liked Pooja Uppalapati
    keyboard_arrow_down

    Pooja Uppalapati - Scaling Agile in a Mainframe Product Development Organization

    20 mins
    Experience Report
    Intermediate

    Agile transformation in any organization will go through myriad of challenges that involves people, existing organization culture, technology/domain etc. Instead of seeing these challenges as obstacles, if you view them as opportunities to grow and improve, transformation will be more impactful and long-lasting. If neglected, the very same obstacles would severely damage the motivation and trust of employees.

    In this experience report we would like to walk you through the agile transformation journey in a Mainframe product development enterprise by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. Specifically we would like to touch upon 

    1. Self-organizing teams
      • Resistance to change
      • Culture shift
    2. HR
      • Lack of role clarity and
      • Effective R&R in agile space
    3. Agile Engineering Practices adopted in Mainframe product development
      • Unit test automation
      • Continuous Integration

    Along the presentation we’ll highlight few anti-patterns and the effects of ignoring them.

  • Liked Ashish Parkhi
    keyboard_arrow_down

    Ashish Parkhi - Gamifying Agile Adoption - An Experiment

    45 mins
    Case Study
    Intermediate

    While having a chat with Naresh Jain, he suggested me to go through the Ted Talk – “Gaming can make a better world” by Jane McGonigal. I found the title very weird and was wondering how is that possible? After going through the talk though, I was amazed. I started wondering if I can use the gamification technique in Agile Adoption, in our Products, in Performance Management Systems, in Employee Engagement Programs?

    Dhaval Dalal introduced me to Prof. Kevin Werbach’s definition of Gamification – “The use of game elements and game design techniques in non-game contexts.

    For our 4th ShipIt Day, organized on 25th/26th Sept 2014 at IDeaS, I decided to explore the idea of using game elements and game design techniques in the context of Agile Adoption. The idea was to create a gaming system which will automatically collect data, i.e. without explicit user intervention,  from multiple sources like Jenkins, Rally and manually from individuals and offer Star’s for positive behavior and deduct Star’s otherwise.

    The aim was to help the team get continuous visual feedback on how they are doing, adopt agile practices, visualize sense of accountability, visualize sense of achievement, drive positive behavior, create healthy competition, create a culture of appreciation, help performance tracking and create transparency.

     

    Landing Page

    User Profile

     

     

     Update - 

    1. Deducting points seems to be bothering the individuals. Now we are experimenting with getting rid of negative points and introducing short lived badeges instead e.g. "Build Breaker". 
    2. We have now added more badges to recognize individual efforts in various categories.
    3. Working on open sourcing the core app at https://github.com/IDeaSCo/rockstar
  • Liked Vinod Kumaar R
    keyboard_arrow_down

    Vinod Kumaar R - Build it like sports teams

    Vinod Kumaar R
    Vinod Kumaar R
    VP Engineering
    Recruiterbox
    schedule 2 years ago
    Sold Out!
    20 mins
    Talk
    Intermediate

    Is it easy to get a crash course in football by Pele or Maradona for a week and produce a world cup winning football team?

    Answer is NO. Then why do lots of people in the corporate world think of hiring scrum trainers & expert developers to train their team for a week and then expect their team to undergo a transformation at a magical scale?

    German football team made it a point to transform their team and it took them a lots of years before they were able to reach the pinnacle. A quick side by side comparison of what is causing agile transformation to fail.

    Vision

    Football: Someone was there owning this entire transformation, the German football association spent a lot of time identifying talent in their teens and groomed them.

    Office: In the corporate world switching jobs every few years have become common, but there is no passing on of the context, resulting in the new person taking charge, starting from all over again, as well as frustrating existing good performers who have to rebuild the perception.

    Infrastructure

    Football: Players expecting state of the art training facilities, fitness programs and new shoes are not a luxury, it is a necessity.

    Office: Computers have become so cheap compared to the salaries, yet the policy of providing the best tools and good work environment are archaic.

    Coach vs Management

    Football: Coaches are given their due powers to help the team achieve the goal. It is very easy for anyone to comment on how professionals should play their game, there would be no use adhering to the metrics if the team cannot win. Winning is the only measure for management.

    Office: Often coaches are seen as part of the management or management tries to heavily influence coaching which results in a team which will work either for metrics or to please higher ups without the actual result that it had aimed for.

    Training

    Football: Just the ability to kick the ball does not make a footballer. Training will be introduced to increase physical strength & stamina, better mental wellness, injury prevention, tactics and strategy.  A heavy investment is made in the training facilities.

    Office: In the software industry a generation is about 2-3 years. Computer science degrees are nowhere near what is state of the art in the industry. At many places the on boarding process is either very shallow or not up to date with the recent developments, leaving people to learn most of the things hard way. Given too many things to learn and the information overload, this results in inefficient learning and application of knowledge on the job. We need to prepare people to find answers that are not available on Google.

    Team composition

    Football: Rookies don’t learn by watching greats from the bench, instead they play along with the veterans. Every sports team makes sure to have the right composition with a mix of rookies, emerging players and veterans. That is how they sustain a winning team.

    Office: Architects and Leads often do not code or are not part of the team every day, this means that most of the time the team just looks up to for advice or waits for reviews. There should be a good mix of people at all experience level so that there are enough people to try new things, enough people who have mastered few things and enough people who challenge change.

    Above all – Persistence

  • Liked Lance Kind
    keyboard_arrow_down

    Lance Kind - Using Fiction to Motivate Change

    45 mins
    Talk
    Intermediate

    Since the late nineties, the Agile books in the non-fiction aisle have steadily increased in number. It's common to see a book or three about Agile on a colleague's desk. It's also common to see such a book look practically new, the book spin showing no sign of having been opened. Non-fiction books are great at providing bullet points of things to do and reasons why. But non-fiction books are poor at:

    • inspiring,
    • creating emotional attachement (so the reader finishes the book), 
    • creating a full sensory environment for the reader,
    • describing a holostic environment, or
    • 'intriguing' a reader who is un-interested in the topic. 

    (This bullet list above is a good example of how non-fiction can excite thoughts who already know the story behind the bullets, but doesn't inspire much if the reader hasn't any context or background.)

    Fiction is well positioned to do the above because its number one job is to give pleasure and entertainment.  It can't be successful if it can't do this. The oral tradition of fiction has been part of human culture for millions of years, since a Cro-Magnon passed on a story to another, and upon re-telling some details were forgotten and the storyteller had to make them up.  Fiction is in fact is the most successful format for culture change as this is the format of the world's religious works and is responsible for guiding or changing the behaviors of billions of people.  The CIA and the Pentagon use fiction to develop scenarios which are used to create simulations to test preparedness.

    What force could be stronger than fiction for giving an individual the courage to initiate an organizational change in the face of uncertain co-workers and often antagonistic corporate environment?  What tester, developer, PM, director could not use the courage of knowing a "David verses the Goliath," "Legend of the IpMan," or "V for Vendetta" to not only understand the bullet points, but to have the stedfast to sustain in the face of resistance because they believe in the change as if they've lived that life, due to reading stories which placed them in one or many virtual versions of that world.

  • Aslak Hellesøy
    Aslak Hellesøy
    Founder
    Cucumber Limited
    schedule 2 years ago
    Sold Out!
    60 mins
    Keynote
    Intermediate

    As lead developer of Cucumber and author of The Cucumber Book, Aslak gets asked to consult with organisations who want to introduce Behaviour-Driven Development (BDD). Time after time, he meets teams who are trapped doing half-arsed agile. They do the easy, obvious, visible agile practices, and none of the powerful, hard-to-master, hard-to-see ones.

    When these teams ask for help learning BDD, we get a chance to remind them how important conversations and collaboration are in software development. We teach them to write tests before they write code, as a way to explore and discover the hidden details of a requirement just before they dive in and start building it. This talk will make you wince with recognition, laugh with despair, and finally inspire you with stories of teams that have finally, after years of flaccid scrumming, discovered the true collaborative heart of agile software development. You’ll see patterns you recognise from your own teams, and gain insights about how to fix them.

  • Liked Jeff Lopez-Stuit, CEC
    keyboard_arrow_down

    Jeff Lopez-Stuit, CEC - The Exorcist Was a Lean Planning Master

    20 mins
    Pecha Kucha
    Beginner

    How can teams that have to deal with large, complex legacy systems get through planning and get to work? The title character of the classic American horror film, "The Exorcist" was a master at this..

    Pecha Kucha Talk Summary:

    • Introduction: Creating understanding through conversation can be very difficult for teams dealing with complex, legacy systems.

    • Introducing Regan McNeil: Poor Regan McNeil was starting go insane, but a team of doctors and specialists in close, face-to-face collaboration, couldn't solve her problem.

    • The Exorcist: The Exorcist knew how to have just enough conversation to get to work, so his team could deliver the value everyone had been working and praying for.

    • Summary: "In life, understanding is the booby prize". Sometimes the quest for understanding can be an impediment to delivering value. Having faith in self-organization, sometimes its best just to get to work.