In lot of agile teams, often times, all the team members will be doing the grooming and planning exercise as a team. Often times, defining the behaviors is either ignored, overlooked, skimped or done by individuals on their own without a common understanding as a team.

To solve this problem, I have used this hands-on time-boxed activity for all of my teams to define behaviors as they move along in the sprint. This will help all the team members to have a shared understanding on their users and their behaviors as it relates to their user story. This is an activity that any agile team member can take and implement the next day at work.

 

 

 
43 favorite thumb_down thumb_up 8 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Discuss on the importance of defining behaviors as a team   
  • Activity 1- explanation
  • Activity 1- Form teams, pick a user story form the list for your team, identify and describe users.
  • Activity 2 - explanation
  • Activity 2 - Teams will be defining behaviors for the user story they picked
  • Teams will share their users and their behaviors to the entire group
  • Retrospective as a group

Learning Outcome

This will be a hands-on workshop where attendees will be defining behaviors as a team for a user story and experience the significance of doing so. Attendees will be able to incorporate this in their teams immediately.

Target Audience

Product Owner, Scrum Master, Tester, Developer, Business Analyst, SME, Agile Coach, Manager, Test lead, or anyone else with a stake in delivering high-quality software

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • AgileSattva Consulting LLP
    By AgileSattva Consulting LLP  ~  1 year ago
    reply Reply

    Hi Pradeepa, topic is interesting as there is a need for teams to understand requirement (given in form of user story or any other form).

    Going through your proposal, would like to understand :

    1. Are you referring "defining the behaviors" to that of the user? or of the user story? is it same as BDD?

    2. You also mentioned in response to Joel's comment, as Naming the users, two examples like "Clumsy clarance, and Tony typist", it would be interesting to understanding the value addition that we would get by adding a name or an "characteristic - clumsy" be helpful in understanding the story? 

    /Deepak

    • Pradeepa Narayanaswamy
      By Pradeepa Narayanaswamy  ~  1 year ago
      reply Reply

      Hi Deepak,

      Thanks for your feedback and questions. Please see my replies below.

      1. Are you referring "defining the behaviors" to that of the user? or of the user story? is it same as BDD?

       I meant defining behaviors for the user as it relates to the user story. Behaviors may very well bleed outside the scope of the story, but that can be uncovered only by having those conversations.

      I love Liz Keogh's take on BDD as she says, talking about the behaviors is more important than putting it in papers than automating them. And i am 100% with her. Whenever you bring any xDD's, people often relate them to tools. I want to avoid that. So i am staying away from using that in this proposal as it may lead to some rat-hole conversations.

      My intent is to stress the importance of having those conversations as a team and i believe this workshop is intented to do that.

      2. You also mentioned in response to Joel's comment, as Naming the users, two examples like "Clumsy clarance, and Tony typist", it would be interesting to understanding the value addition that we would get by adding a name or an "characteristic - clumsy" be helpful in understanding the story? 

      Absolutely. A Clumsy Clarence is a perfect example to discuss behaviors of an user who is Clumsy and what all can happen if they use the system.

      Also, i have seen teams love naming their users. It gets them closer to their users and help them see the system from that user's perspective.

       

      Hope this helps. Please let me know if you have additional questions or need further clarifications.

      Thanks.

      Pradeepa

       

      • AgileSattva Consulting LLP
        By AgileSattva Consulting LLP  ~  1 year ago
        reply Reply

        Thanks for your response Pradeepa, Just another question again on the behavior of the user, How would you attach a behavior to the user? (for example as clumsy) is it based on an assumption that you come up with the team?

        • Pradeepa Narayanaswamy
          By Pradeepa Narayanaswamy  ~  1 year ago
          reply Reply

          Hi Deepak,

          Thanks for your question. Response below.

          How would you attach a behavior to the user? (for example as clumsy) is it based on an assumption that you come up with the team? As a team if you have a good understanding on the product vision and users(hopefully you include your PO and UX), then as a team its not be too difficult to define the personalities for your users. Also, because of the short development cycles and faster feedback from customers, as a team you can always refine and redefine your users' behaviors for the next cycle.

          Hope this helps.

          Regards,

          Pradeepa

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

    Your 'links' is a copy and paste of the same from another session.  Are you taking one session from the agile conference and creating two sessions here?  I'm just trying to understand the overlap in the links, etc

    You are referencing this as design behaviours - is this the same as personas from Alan Cooper?

     

    Best,

    Joel

    • Pradeepa Narayanaswamy
      By Pradeepa Narayanaswamy  ~  1 year ago
      reply Reply

      Hi Joel,

      Opps, that was a copy paste error. I corrected that in my proposal.

      This workshop was not given for public yet. This will be my first time. Although, i have done this activity many times with the agile teams i work with.

       

      You are referencing this as design behaviours - is this the same as personas from Alan Cooper?

      Did you mean "Defining behaviors"?  It is kind of like personas. But not quiet. I expect the name of the users to exhibit some traits that will build up behaviors that may be unique to that user. Example: Clumsy Clarence fatfingers wrong date, Tony Typist enters valid Visa card number  etc.. I have seen teams love naming their users. And they were able to relate to their users in defining bahaviors when they name them instead of being hand over as pretty persona posters by their UX team. Again, i am all for UX as part for cross-functional team and they will be part of this activity with the rest of the team and they will have their insights when it comes to defining bahaviors.

       

      Hope this helps. Please let me know if you need additional information.

       

      Regards,

      Pradeepa

  • Sachin goel
    By Sachin goel  ~  4 years ago
    reply Reply

    Hi

    Curious to go little deep into this particular aspect  "This will help all the team members to have a shared understanding on their users and their behaviors as it relates to their user story."

    Are you planning to include the benefits of having common understanding of behaviour? how does same help agile team in their next / current sprint ?

    thanks - sachin

    • Pradeepa Narayanaswamy
      By Pradeepa Narayanaswamy  ~  1 year ago
      reply Reply

      Hi Sachin,

       

      Appreciate your curiosity. Yes, the benefits will be discussed in the retrospective section of the workshop. That will also include the discussion on how it is going to help the teams on where to focus while testing their stories. If the team discovers and uncovers various behaviors that may not be part of the scope for their current sprint, the PO can take it on to determine next steps.

       

      Hope this helps.

       

      Regards,

      Pradeepa


  • Liked Bernd Schiffer
    keyboard_arrow_down

    Bernd Schiffer - Net Promoter System for Agile Companies

    45 mins
    Talk
    Intermediate

    Customer collaboration is essential to every Agile business. To create and collaborate to keep a customer is the purpose of an organisation. But still lots of companies try to make bad profits, i.e. profits earned at the expense of customer relationships. The Net Promoter System (NPS) is a renowned open-source system which addresses and measures customer collaboration. And did you know that you not only can use it to get feedback on your products and services, but also on your employees and your personal performance?

    NPS is a perfect fit for Agile companies - and those who want to be. Most of the companies I worked with (Agile coaching, training, consulting) had not heard about it, and far less were actually using it. This really surprises me, since NPS integrates like a charm with Agile, e.g. within product development via Scrum.

    In this session I'll explain the basics of NPS, i.e. promoters and detractors, satisfied and delighted customers, bad profits (how to deal with bad feedback?) and good profits, and why and how to measure these. Several stories from companies like Apple Retail, Zappos, Southwest Airlines, and others will help to make my point. I’ll further show why NPS is a very good fit with Agile regarding products, employees, and personal performance. Dos and Don’ts regarding NPS (also from personal experience) will close this session. Related to the Don'ts, I also cover some of the negative critiques out there.

  • Liked Victoria Schiffer
    keyboard_arrow_down

    Victoria Schiffer - Agile Coaching? Sure thing! What about Life Coaching in Agile Thinking?

    Victoria Schiffer
    Victoria Schiffer
    Agile Coach
    SEEK
    schedule 4 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    I love being around awesome people, who build great products customers desire. 
    I love learning from and together with these amazing minds. 
    I love creating the right environment for teams to flourish. 
    I love change, and learning from new experiences. 
    I love working in Agile environments.

    How about you? 
    I bet there are some elements of this list why you're in Agile, too. And you can probably add even more elements to it.

    The Agile Manifesto states amongst others individuals and interactions, customer collaboration and responding to change.

    In our everyday life doing Agile we already respect these aspects in many ways. 
    But do we practice what we preach as best we can?

    I'd like to challenge your current way of thinking about people and processes. 
    I'd like to challenge you to focus on you, before you focus on others. 
    I'd like to challenge your current way of reflecting. 
    I'd like to inspire you to go different ways. 
    I'd like to inspire you to inspire others.

    In Agile we're already good in improving our processes and creating well performing teams and hence building the right things in the right way. And in the Agile Manifesto's communication and collaboration piece we can even get better.
    "You have not yet reached the limit of what you're capable of!" means we can always further improve. And we do follow this idea in our Agile processes, too, through continuous feedback (Retrospectives) and improvement.

    And why not take it even further? Why not go "Beyond Agile"?!

    Here's where aspects of Life Coaching come in handy: through also understanding and improving ourselves (how do we interact with people due to how we perceive our environment) we will even further improve communication and collaboration.

    Life Coaches believe our clients know the answer. And even if Agile Coaching is slightly different than Life Coaching, I see it as very relevant in Agile Coaching, too. If we apply this in Agile, instead of giving our clients (team, colleagues) the answers, asking them powerful questions to help them be more aware of what's happening at the moment, they will find their answer for it and will have a much better commitment to making the change for themselves, their teams and the company. It's not for us to TELL them what to do, but to ASK them what's going on for themselves. Here's where I see a huge chance for improvement.

    In my session I give lots of examples on how to link Life Coaching ideas to our Agile work environments. I've given the session at LAST Conference Melbourne and at the Agile Coaching Circles Meetup Melbourne. The audience was engaged and the attendees were very happy about having some new ideas on how to improve their daily work life.

    Come along to be inspired by Life Coaching and thus to benefit our Agile Thinking!

  • Liked Giovanni Asproni
    keyboard_arrow_down

    Giovanni Asproni - Methodology Patterns: a Different Approach to Create a Methodology for Your Project

    Giovanni Asproni
    Giovanni Asproni
    Consultant
    Asprotunity Limited
    schedule 4 years ago
    Sold Out!
    90 mins
    Tutorial
    Advanced

    In the software world we have been looking for “The Methodology” to solve our software development sorrows for quite a while. We started with Waterfall, then Spiral, Evo, RUP and, more recently with XP, Scrum, Kanban, DAD, SAFe (there are many others, but, their impact, so far, has been limited).

    In this tutorial, I'll show why this search for the holy grail is bound to fail--each methodology has strenghts and weaknesses that make it suitable only in some contexts--and I'll describe a different approach based on patterns and pattern languages, that teams can use to create their own methodologies to suit their specific needs, which, in my experience, has a higher chance of success. 

    The approach is based on the observation that all the practices used in all modern methodologies--e.g., user stories, use cases, team self organization, TDD, unit testing, acceptance testing, continuous integration, iterative and incremental development, etc.--come from the same set. Different methodologies just mix and match them differently. All those practices can (and many have already been) described as patterns whose relationships with each other form a set of pattern languages.

  • Liked Naresh Jain
    keyboard_arrow_down

    Naresh Jain - Scaling XP Practices inside your organization using Train-the-Trainer Model

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 4 years ago
    Sold Out!
    90 mins
    Workshop
    Advanced

    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.

    The goal of this workshop is to explore what other successful models organized have used to scale skill-based training in their organization.

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

    "Release Early, Release Often" is a proven mantra and many companies have taken this one step further by releasing products to real users with every commit a.k.a Continuous Deployment (CD).

    Over the years, I've built many web/infrastructure products, where we've effectively practiced CD. However at Edventure Labs, when we started building iPad games, we realized there was no easy was to practice CD, esp. given the fact that Apple review takes a few days.

    Our main question was: As mobile app developers, how should we architect/design our apps for CD?

    We were a young startup, learning new behavior about our users (kids aged 5-8) everyday. We could not afford any delay in releasing latest, greatest features to our users. To solve this problem, I believe we've built an innovative solution to enable any mobile app developer to achieve CD.

    If you are building real products, which have platform/3rd-party dependencies and you want to practice CD, this session is for you.

  • Liked Pramod Sadalage
    keyboard_arrow_down

    Pramod Sadalage - Ten Patterns of Database Refactoring

    Pramod Sadalage
    Pramod Sadalage
    Developer
    ThoughtWorks
    schedule 4 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Over the life of an application as requirements change, application usage patterns alter, load and performance changes the need to change database and database architecture is inevitable. There are patterns of these changes such as

    1. 1. Encapsulate Table with View
    2. 2. Migrate method from database
    3. 3. Replace method with views
    4. 4. Introduce Read only table
    5. 5. Split table
    6. 6. Make column non-nullable
    7. 7. Drop column
    8. 8. Add foreign key constaint
    9. 9. Merge columns
    10. 10. Replace columns

    In this talk we will discuss the above database refactoring patterns and different implementation techniques to enable blue, green deployments, allow for legacy applications to work with fast changing database and enable the teams to effectively refactor the database to fulfill the changing needs of the organization.

  • Liked Cara Turner
    keyboard_arrow_down

    Cara Turner - Building Creative Teams: Motivation, Engagement and Retrospectives

    Cara Turner
    Cara Turner
    Agile Coach
    Khanyisa Real Systems
    schedule 4 years ago
    Sold Out!
    90 mins
    Talk
    Advanced

    How do software teams become creative? If you're not a start-up, does creativity even play a role in the business driven world of software development? Idea generation is the basis of all our work - no matter how challenging or mundane. With a scientific approach to implementing change, creativity is the basic tool we have for addressing the challenges of software development.

    This talk explores the elements of engagement and creativity along with the neuroscience of generating ideas. These give us specific insight into how employing different agile retrospective formats over the course of the product development process can extend our usual practices and develop a thinking mind-set comfortable with tackling daily work with a fresh and explorative approach.

  • Liked Johannes Brodwall
    keyboard_arrow_down

    Johannes Brodwall / Buddhima w.wickramasinghe. - Practice agile programming with coding dojo

    90 mins
    Workshop
    Beginner

    A Coding Dojo is a fun and social way to become a better programmer. Johannes is an experienced coding coach who will guide you through a few hours of programming that will transform your understand your craft and yourself as a programmer. In the workshop you get to try out pair programming, test-driven development and continuous refactoring for yourself and you get lots of recommendations on how to improve your coding and testing. You will need to bring your own computer with a development environment of your choice. Recommended for Java, Ruby, JavaScript and C# developers.

    This is what previous participants say about the workshop:

    • What did you learn? New tools, pair programming and fun exercises; Ide tricks, programming language basics, testing tools, using tests as a reasoning tool; you can comfortably pair with strangers.
    • What surprised you? Small steps work better than planning; It's easy to get started when you pair program; Pair programming is nice
    • What do you plan to do next? Using TDD every day; Listen to partner more carefully - he may already have solved the problem.
  • Liked Johannes Brodwall
    keyboard_arrow_down

    Johannes Brodwall / Niruka Ruhunage - Remote Pair Programming

    45 mins
    Demonstration
    Beginner

    Can you maintain agile engineering practices with a distributed team?

    Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. In order to promote agile engineering practices, he uses remote pair programming to connect with teams halfway across the world.

    In this talk, we will go through a practical approach for remote pair programming adopted for high-latency situations. We will demonstrate remote pair programming with a live example and we will discuss the advantages and usages of the approach. We will also cover the practical parts of remote pair programming, such as tools and setup.

    After seeing this talk, the audience should be able to remotely pair with members of their distributed team. They will also get a lot of tips on how to use pair programming effectively in both local and remote settings.

  • 20 mins
    Experience Report
    Intermediate

    The webMethods R&D division of Software AG (wM) produces industry-leading enterprise products focused on application integration, business process integration and B2B partner integration. This division with more than 450 engineers across 7 locations in the world embarked on the journey of adopting Agile and Lean Software Development practices in 2010.

    The Pain

    The wM business line consists of about 40 Scrum teams delivering more than 30 enterprise products that constitute the webMethods suite across 7 locations in the world. Circa 2007, the suite was a loose collection of multiple products individually developed by teams, many of which were brought together by M&As. It was a hard, painful challenge to integrate and test these products as a single suite and synchronizing major releases. The teams embraced Scrum as the development model - a useful first step but still far from guaranteeing predictability, high standards of quality and productivity at the suite level.

    The Challenge

    • Align multiple, small scrum teams distributed over many locations to one Suite Backlog. Focus them on delivering an integrated Suite by modeling an assembly line from a Lean Manufacturing system. The teams develop and contribute to a single value stream with continuous flow and deliver potentially shippable Suite Build Sets in predictable intervals (4-6weeks).

    • Retain the simplicity of the ‘Agile model’. Allow teams to grow at their pace. The teams work off their individual team backlogs, the suite complexities and priority conflicts largely hidden from them. They experiment with their processes, drive their own local changes and share the learning with the other teams.

     Success:

    Since embracing Lean and Agile practices, we have delivered three successful major Suite releases on time with measured quality. The customer situation has dramatically improved with steadily decreasing customer incidents, response times and hot escalations. More than a 100,000 automated regression tests  verify the suite and we have a potentially shippable Suite build set every 4-6 weeks guaranteeing the highest standards of quality. For faster value delivery, we are now transitioning to 6-monthly releases – the first of which is due to roll out in Q4 2013.

    In this Experience report, I focus on how we aligned scrum teams operating from Germany, U.S, Bulgaria and India to a single backlog, a continuously integrated Suite and a potentially shippable single build set delivered every 4-6 weeks. We will look at the challenges we faced, custom solutions and processes that we designed to realize the Single Suite Vision.

  • Liked Vinod Sankaranarayanan
    keyboard_arrow_down

    Vinod Sankaranarayanan / Pravin Kumar Thakur - Introducing Agile Knowledge Transfer

    20 mins
    Experience Report
    Beginner

    After more than 5 years of supporting the thetrainline.com platform, ThoughtWorks worked with The Trainline teams to transfer knowledge and context  back to the Trainline Teams.

    This methodology was co-created by ThoughtWorks and Trainline as a healthy sustainable and mature way to transfer knowledge. The transition itself was about a year long and involved multiple agile concepts around remote pairing, program MVP and above all, continuous delivery and non-disruption to business through the process.

    This presentation would take the audience through the experiences and learnings of the process. This session is co-presented by ThoughtWorks and Trainline (vendor and customer) and will provide an insight across multiple spectrums of delivery and business.

  • Liked Nikhil Joshi
    keyboard_arrow_down

    Nikhil Joshi - Build - Measure - Learn : Without spending a fortune

    20 mins
    Experience Report
    Beginner

    At times we have great product ideas but the biggest barrier to entry lies in answering few questions such as:

    - How do I define and validate Problem hypothesis, Solution hypothesis and Underlying assumptions?

    - How do I quickly setup a platform for people to register their interest?

    - What will keep the potential customers engaged, excited until the first release (or beta) is out?

    - How do I get feedback from the early adopters?

    - And eventually when I have answers to some of these questions, how do I make a decision to persevere or pivot?

    If you've faced a challenge while answering any of these questions while building/validating your product idea, this session is for you. We'll look at tools and techniques to validate the product hypothesis early-on without spending months or fortunes. We'll also look at a case study to highlight how some of these tools, techniques helped us validate our product idea.

  • Liked Abhilash Chandran
    keyboard_arrow_down

    Abhilash Chandran - Retrospectives with large projects and (or) multiple teams

    20 mins
    Experience Report
    Intermediate

    Retrospectives are the one of the most integral components of any agile methodology.  In scrum a retrospective is typically done after each sprint. This process is simple if team is small or only one team is working on a product. The problem starts increasing exponentially when many teams work on a single product. All the teams have ideas to improve the process and production.  One team may have an entire opposite idea of another. How to bridge this gap?

    Last project executed across different teams (onsite & offshore) and different departments was not a great success. How to learn from the past failures and apply it to future projects?

    In this discussion, I will be talking about some the points which can be easily followed in such scenarios. 

    Why did we did this?

    Normally in a scrum environment we have a single team with Product Owner; they do the retrospectives within team. Team identifies the issues and work on them. Many team falls into this category. It is pretty simple

    Let’s complicate this further.

    • A big product with 10 scrum team
    • Each Team has different PO

    Apart from these main stake holders there are many others who are interested in the success of this application

    • Sales team
    • Documentation team
    • UI design team
    • Architecture and performance team

    In such a scenario, a retrospective at team level will be effective only at granular level. But it leaves a gap in few areas; it helps to bring all the teams together for one big retrospective

    • Apply the improvements made at each team level to the whole program
    • A team's retro action item against the process followed by another team can be discussed at a higher level to find an optimal solution
    • Sometimes two team's retrospective action items may be contradictory. This gathering may point a third solution
    • Sr Product owners and manager will get all the teams together. A common focus and improvement plan can be shared across teams.
    •  All team gets to know about the key concerns at the program level and with other teams.
    • Ultimately it gave a feeling of one big family.

    My experience

    Last large retro organized in our group was a big success. The sales team & architecture team had many ley lessons to take back from this meeting.  Many issues were bought out which could have been solved with better co-ordination across team.  Concrete action plans were made by team for the subsequent release.  Some of the key findings were shared across other program teams also.

  • Liked Ram Srinivasan
    keyboard_arrow_down

    Ram Srinivasan - The Conflict Paradox

    90 mins
    Workshop
    Intermediate

    It is not a question of if a team is going to have a conflict; it is a question of when. Equipping them to deal with conflict is more than creating agreements or having a good facilitator. We look at a conflict model that focuses on dynamics of conflict by understanding- 1. Cognitive skills:self-awareness about triggers, hot spots, emotions,behaviors. 2. Emotional skills:reading emotions, body language, balancing emotions, using curiosity 3. Behavioral skills:understanding others’ perspectives and needs, avoiding 8 destructive behaviors, embracing 8 constructive behavior. In an organizational setting, it is important to understand the source (culture, interdependence, incompatibility, personality, power, etc.) and types of conflict (cognitive vs. affective). Creating awareness about conflict processes, retaliatory cycles and building a conflict profile can empower teams engage in constructive disagreements. 

  • Liked Colin O'Neill
    keyboard_arrow_down

    Colin O'Neill - Achieving Enterprise Agility with the Scaled Agile Framework...and Have Fun Doing It!

    90 mins
    Tutorial
    Intermediate

    Scrum, XP, Kanban and related methods have been proven to provide step changes in productivity and quality for software teams. However, these methods do not have the native constructs necessary to scale to the enterprise. What the industry desperately needs is a solution that moves from a set of simplistic, disparate, development-centric methods, to a scalable, unified approach that addresses the complex constructs and additional stakeholders in the organization—and enables realization of enterprise-class product or service initiatives via aligned and cooperative solution development.

  • Liked Vinodhini
    keyboard_arrow_down

    Vinodhini / Thushara Wijewardena - Robotic Warehouses, Alien Domain, Offshore developers, Visionary customer : Saved by agile

    20 mins
    Experience Report
    Intermediate

    Here is a case study of how agile outsourcing can be practically applied even when the business domain is very complex and alien to offshore teams.
    The example is a project in which Exilesoft provided for a leading Norwegian producer of Robotic warehousing solutions. The project involved transforming their legacy application, produced using multiple suppliers and methods, into a newly cast application solution. This project also had its own share of typical challenges.

    • Lacked definitive and reliable documentation,
    • Domain knowledge was limited to a few very busy individuals,
    • Development and redeployment could not interrupt attention to current customers,
    • Complexity was high and design was fragmented, and
    • Focus heavily invested on current product and customer support

    These limitations along with the lack of understanding of agile methods strongly suggested the use of a method adaptive in nature, and not heavily vested in large inflexible legacy elements.
    We commenced the engagement with two pivotal elements; client awareness (agile orientation) and a roadmap of committed involvement. To lay credibility this had to be backed up with proven result delivery in the very early stages. It allowed for flexible adaption, and the creation of an atmosphere that fostered client interest.

    During this session, we will take the audience through a small video clipping of such a warehouse. We will elaborate how the customer and offshore developers worked together using agile in a highly integrated team collaboration model to achieve success within a very short time frame.

    The session will cover the following key areas:

    How such projects can be initiated

    - What type of team model and contract type we used

    - How we did the agile transformation with the customer

    - How the roles were assigned between offshore and onshore team members

    - To improve remote collaboration the tools and techniques we used

    - Techniues learned to get teams up to speed with the new domain

    - As we go along, the process changes we identified and implemented to make things work better.

    - Agile engineering practices and team dynamics that helps in such situations

  • Liked Prasanna Vaste
    keyboard_arrow_down

    Prasanna Vaste - Should we stop using Story Points and Velocity?

    Prasanna Vaste
    Prasanna Vaste
    Business Analyst
    Thoughtworks
    schedule 4 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    On Agile projects we estimate user stories in order to allow team to

    1. 1. Track velocity
    2. 2. Decide scope for the Iteration
    3. 3. Help Prioritize stories
    4. 4. Help Release planning

    But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.

    Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.

    I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.

  • Liked Allen Rutzen
    keyboard_arrow_down

    Allen Rutzen / Sunil Roy - Nokia Maps Agile Journey.....(Agile Transformation, Scaling and Overcoming Challenges)

    45 mins
    Talk
    Intermediate

    We (at Nokia Maps Division) began our Agile Journey in 2009, with a Top Down approach for Agile Transformation. The formation of an Agile Working Group (with members having Agile experience behind them) at two major sites was instrumental in shaping the transformation and scaling and also overcoming the challenges from time to time.

    The challenges were huge, but our spirit was bigger, and the high level strategy was decided. Interestingly, the Agile Working Group itself ran the whole Transformation and Scaling program using Agile values and Scrum frame work. Scrum was also used as the preferred framework for the agile projects (after success in our pilots), except where Scrum would not work. Kanban or hybrid methods were used in those few teams.

    What were the challenges faced, and how did we overcome them? What values helped us in our transformation journey?

    How did we migrate to the Scaling phase? What helped us in scaling and stabilizing?

    Can we rest easy now? Of course not!

    What are the next steps? And of course, the challenges ahead?

    Let us share our Nokia Agile journey with you, and help you all be successful too, in your Agile journey!

  • Liked Mushtaq Ahmed
    keyboard_arrow_down

    Mushtaq Ahmed - Using a modern web framework for big enterprise agile project

    Mushtaq Ahmed
    Mushtaq Ahmed
    Mr Scala
    ThoughtWorks
    schedule 4 years ago
    Sold Out!
    20 mins
    Demonstration
    Advanced

    At ThoughtWorks, a 50-people team is building a marketing website backend for one of the largest consumer electronics brands in the world. We are Play-Scala as our web framework which allows us to design the application in a very different but powerful ways. This experience based talk will talk about these differences, emphasizing on two of them: "Dealing with concurrency without threads" and "Dependency resolution with constructor injection".

    Dealing with concurrency without threads
    - The backend is end to end non-blocking with highly concurrent architecture
    - Each page consists of 20+ reusable snippets, so each page request translates into 20+ outbound web service calls to get data for the snippet data in parallel
    - Posting data involves download/upload of large images from/to remote services, also done in parallel
    - We will show you how Scala Futures, Play and ReactiveMongo functional programming paradigm allows us to do all this without blocking any thread or managing thread-pools by hand

    Dependency resolution with constructor injection
    - Dependency injection is considered essential for designing applications that are easy to test. Usaully, dependencies are specified as constructors parameters
    - Scala traits allow us to get rid of constructors by wrapping classes and their factories inside components that in turn can depend on other components, this enables a compile time mechanism for dependency resolution which is very flexible
    - We will show examples of this pattern, its effects testing without external DI frameworks

    We will briefly talk on how functional programming style in general helps with testing and software delivery on agile projects. Finally, we will also cover the pain-points these approaches bring out, and argue if it is worth to pay that cost.

     

     

  • Liked Gerry Kirk
    keyboard_arrow_down

    Gerry Kirk - Create an Agile virus in your organization, empower your team, change your life

    90 mins
    Tutorial
    Beginner

    Need buy in from a key manager or executive to adopt Agile? Desiring better team collaboration? Hungry for a saner life at home?
    Try Personal Kanbanwinner of the Shingo prize for Operational Excellence. It's the fastest, simplest way to taste test the goodness of the Lean Agile approach to managing knowledge work. Personal Kanban empowers small teams and individuals, at work and at home.Give that overwhelmed executive instant relief. Build your own system, and soon curious onlookers ask and then create their own. Look out, you've just released an Agile virus in your organization!
    You've also discovered a way for you and your team to get more out of your efforts, to improve communication, and find time for the things that matter most.In this session you'll learn how to create a Personal Kanban system through stories, examples and interactive exercises. Walk away understanding the psychology behind visualizing work and limiting work in progress, inspired and motivated to make a difference at work and home.