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.

 
24 favorite thumb_down thumb_up 27 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

We will look at problems Agile team faces with story points. We will also look at the alternative to story points and velocity and will share project experience.

1. Introduction

2. Why we estimate stories in Agile Projects?- 5 Min

3. Problems we face with estimation - 5 min

4. Alternative to estimation and Experience report from project explaining how it helped - 10 min

 

Learning Outcome

Learn more about better alternative for story points and velocity and how to use it on Agile Projects.

  • How to determine the price for your customer without estimating user stories.
  • How to determine delivery dates and roadmaps without estimation rituals
  • How to do Agile projects without estimating user stories.

Target Audience

Business Analyst, Project Managers, Developers, Iteration Manager, Scrum Master

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Tathagat Varma
    By Tathagat Varma  ~  3 years ago
    reply Reply

    Prasanna - could you pl share a presentaiton outline/strawman so that the review panel could start getting more clarity into the final presentation and share its feedback accordingly?

    thanks, TV

    • Prasanna Vaste
      By Prasanna Vaste  ~  3 years ago
      reply Reply

      Hi Tathagat,

       

      Yeah sure. As mentioned in the confirmation email, I will share outline/strawman before Nov 15th

  • Prasad
    By Prasad  ~  3 years ago
    reply Reply

    Prasanna,

    Still how will you determine the value of story that you delivered? how do you know how much budget you need to execute the project.?

     

    • Prasanna Vaste
      By Prasanna Vaste  ~  3 years ago
      reply Reply

      Hi Prasad,

      For me the value of the story is based on how much value it created for business or end users. Goal if any user story is to deliver value to end users. If you say we deliver 5 point worth of user stories in this Iteration, but ultimatly the value of the story is determined by its end users. Story points can't tell you how much value the story was worth it. You can still plan your releases and your project budget using story count as measure of velocity and thats what I will talk about in the presentation.

    • Prasanna Vaste
      By Prasanna Vaste  ~  3 years ago
      reply Reply

      Hi Prasad,

      For me the value of the story is based on how much value it created for business or end users. Goal if any user story is to deliver value to end users. If you say we deliver 5 point worth of user stories in this Iteration, but ultimatly the value of the story is determined by its end users. Story points can't tell you how much value the story was worth it. You can still plan your releases and your project budget using story count as measure of velocity and thats what I will talk about in the presentation.

  • Tathagat Varma
    By Tathagat Varma  ~  3 years ago
    reply Reply

    Hi Prasanna - one more question. Have you delivered any previous talk/presentation on this? While your idea seems interesting to the intended audience, the reviewer panel would also like to understand how was the response from practitioner perspective to some of the ideas that you propose, and also to understand your style of presentation.

    -TV

    • Prasanna Vaste
      By Prasanna Vaste  ~  3 years ago
      reply Reply

      Hi,

      I did talk on this in Thoughtworks internal events. I haven't presented yet in any outside conferences.

      As part of presentation, I would like to talk about the issues different teams faced while estimating stories in points and will then present how I went about solving these issues by using story count.

  • Ted Tencza
    By Ted Tencza  ~  3 years ago
    reply Reply

    Hi Prasanna. Can you please add more details about the contents of your talk. The problems you outline, can they be understood to be people using agile estimation incorrectly, or are you saying that story points when used correctly still have these flaws? Also, would you please give some more specific details about the alternatives to story points. What are they, how do they work, and why are they better?

    • Prasanna Vaste
      By Prasanna Vaste  ~  3 years ago
      reply Reply

      Hi Ted,

      I have updated the proposal based on your feedback.Hope this helps.

      • Ted Tencza
        By Ted Tencza  ~  3 years ago
        reply Reply

        Thanks.  One more question.  Are you saying that all stories are created equal, so any 5 stories are equivalent to any other five stories?  How do you account for varations in story size when planning based on past story count perfomance?

         

         

        • Prasanna Vaste
          By Prasanna Vaste  ~  3 years ago
          reply Reply

          Hi Ted,

          When using story count, assumption is that all stories are of same size. Story point is just an indication of story complexity and effort involved, it doesn't provide accurate estimate for the time required for developing the user story. So to explain how this works out. Don't estimate the size of a story when doing Iteration Planning just ask: can this Story be completed in an iteration by pair of devs? If not, then break the story down.

          To answer your second question around variations in story sizes, well when Agile team starts working on project there are more unknowns and as we progress and unknowns are uncovered teams are able to predict better. At start there will be some uncertainty around velocity but one can use the yesterday's weather as input for planning future Iterations. over a period of time variation sizes will get offset.

           

          • Tathagat Varma
            By Tathagat Varma  ~  3 years ago
            reply Reply

            How do you validate the premise that all stories are of same size? Further, how do you ensure that?

            • Prasanna Vaste
              By Prasanna Vaste  ~  3 years ago
              reply Reply

              Hi Tathagat,

              I know that it will be difficult to size all stories of same size. In my past projects, we asked developers to look at all stories and see any of these stories can't be done in an Iteration. In that case, the story needs to be broken down further. I am not saying stories have to be exactly of the same size. All stories should be relatively more or less similar to each other. It might happen that some stories might be smaller or larger compared to other stories. But over a period of time this difference in sizes will get offset. Also, one can look at yesterday's weather (past Iteration velocity) to predict the velocity for future Iterations.

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

    Hi - how do you deal with ambiguity in story count scenarios? in your past experience, what challenges did you face in carving out similar stories? Did it take much time to get mature?

    I guess a lot of us are "stuck" with count than any other parameter, which sounds so silly..but who knows that brings a new dimension in our thinking :)

    thanks - Sachin

    • Prasanna Vaste
      By Prasanna Vaste  ~  3 years ago
      reply Reply

      Hi Sachin,

      In my experience, it doesn't require any additional effort in taking out similar stories. As you do in any other agile projects, identify stories using INVEST principle and check with developers if these stories can be completed in an Iteration. If the team feels that any of identified stories can't be done in an Iteration then broke down further. You can ask development team to check if all these stories are relatively similar and in case they are not then split these stories further. Over the period of time any varation in story size will get offset. On my past project , it took 2-3 iterations for team to get used to story count as measure of progress.

  • Siddhi
    By Siddhi  ~  3 years ago
    reply Reply

    This topic might be a better fit for the agile-lifecycle track. There are many teams (Kanban teams for example) that already use alternatives to story points and velocity -- using lead time for example. In my opinion, this is a core agile topic rather than Beyond Agile.

    • Prasanna Vaste
      By Prasanna Vaste  ~  3 years ago
      reply Reply

      Hi Siddhi,

      I am fine with this. Not many teams use story count for tracking project progress so I thought putting it under beyond agile makes sense. I am open to suggestions on the change in category. Let me know if Organizing team wants me to change the category.

  • pradeep panda
    By pradeep panda  ~  3 years ago
    reply Reply

    Dear Prasanna,

          Believe me this is one of the issues even i face in my team. So I am really looking forward to the session. But at the same time, it will really be nice, if you can provide some more information about your session. From the abstract, i am getting a feeling that, there shall not be any estimation during planning (as it says no estimation ritual) and still you will be able to calculate the velocity of the team. Can you please talk a little about alternatives you are mentioning in the abstract? I still feel some more hints need to be there for us to get a silhoutte of the session. 

    • Prasanna Vaste
      By Prasanna Vaste  ~  3 years ago
      reply Reply

      Hi Pradeep,

      Good to know that you are interested in the session. As you guessed there won't be any estimation during planning, instead will use count of completed stories to calculate the velocity. I have mentioned that in abstract. Using count of completed stories, one can calculate velocity and also predict the future itertaions.

      • pradeep panda
        By pradeep panda  ~  3 years ago
        reply Reply

        Hey Prasanna,

           I really appreciate your quick response. Just adding to what Ted has asked, can you also clarify, if there is no planning, who decides the story points for BLIs?  And if I am not wrong, story point calculation is also a mechanism of estimation. I am Scrum Master of two teams. We do estimation through story points. Identifying velocity from completed story points is I suppose something common which all of us do, is not it? So i really feel, something "HATKE" is there in your presentation, which is not coming out from the abstract. So some clarity will definitely help us in understanding the essence of the presentation.

        • Prasanna Vaste
          By Prasanna Vaste  ~  3 years ago
          reply Reply

          My point is story point is an indication of story complexity and effort required, it can't provide accurate estimate of number of days required or effort required for completing user stories. As i mentioned in my abstract, one can use count of stories completed in past iteration to predict the team velocity for future iterations. Story count can be used for planning purpose instead of story point. i have done this on few projects in the past and it worked really well.

          • Venkatraman L
            By Venkatraman L  ~  3 years ago
            reply Reply

            Hi Prasanna,

            I have few queries regarding this approach. How do you write the stories up ? Does it not constraint the person who is writing up the stories to break them up in the same complexity ? Should it not be very free flowing so that the thought is about "what needs to be done" than "how complex it is". Can you clarify how the stories are scoped out ? I hope I have understood it right.

            • Prasanna Vaste
              By Prasanna Vaste  ~  3 years ago
              reply Reply

              Hi Venkatraman,

              Valid question. When you write user stories, you keep in mind INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) principle. I don't think you need to do anything extra to identify stories of similar sizes. It doesn't have to be exact similar. You can identify stories which are more or less similar. If the team feels that few stories are bigger in size and won't fit in iteration then you can choose to split them. Over the period of time variation in sizes will get offset.

               

              • Venkatraman L
                By Venkatraman L  ~  3 years ago
                reply Reply

                Thanks Prasanna. I understand the INVEST method of writing the user story. However, I am afraid I am a bit unclear on few things. Would be great if you can clarify. Following this pattern, don't you think #stories can be bloated / reduced based on how the teams require it to be? I am not saying we do not trust the team. Trust is core to agile. But, in case of IT services where there is an external customer than an internal PO, how is the billing and payments managed if its purely based on the #? Even if you do not do story points, do you take in to account the business value point of the stories so that the team picks the high value ones ?

                • Prasanna Vaste
                  By Prasanna Vaste  ~  3 years ago
                  reply Reply

                  As I said, business value is core part of any user story. It will always be considered and discussed with client before team picks up any functional story. If team chooses to keep stories of smaller sizes, that menas team will be able to complete more stories in an Iteration, which means you will use this as benchmark for future iterations and plan accordingly. On similar lines if the team chooses to keep stories of large sizes then, team will be able to complete lesser stories in an Iteration and that will be used as benchmark while planning future iterations. One needs to make sure that all stories are more or less similar and are relatively sized. 

                  My problem with estimating in story points is that, team spends lot of time in estimation which can be avoided and this time can be used to deliver value to customer. For planning purpose one can use story count and this has worked with my team while working with some of our clients.

  • Arijit Sarbagna
    By Arijit Sarbagna  ~  3 years ago
    reply Reply

    Hi Prasanna,

    Your statement "count of stories completed in an Iteration as measure of progress" is definitely going to raise a lot of eyebrows (mine included). Keeping aside the lengthy discussion about size & effort - do you really wish to bring a new concept (which we can debate - has a lot if limitations) or try & provide solution to the actual problem of story points? My fear is - by introducing a concept like this, we are going to create more confusion, than solving few. :)

     

    • Prasanna Vaste
      By Prasanna Vaste  ~  3 years ago
      reply Reply

      Well this is not new concept, more and more agile teams have started using story count as measure of progress instead of story point. I find this technique much more simple and less time consuming compared to estimating individual user stories.


  • Naresh Jain
    Naresh Jain
    schedule 3 years ago
    Sold Out!
    45 mins
    Workshop
    Advanced

    As the popularity of Agile methods have grown, so have the misconceptions or myths associated with Agile also grown. These myths get even more glorified when we talk about them in the offshore or distributed context. And to make matters worse, you can throw in a fixed-price contract spanner into the engine.

    Worry not! In this fun-filled activity, we'll collect facts from the participants that they believe are true and then we'll declare them as confirmed or busted after an interactive (heated) discussion.

  • Corey Haines
    Corey Haines
    schedule 3 years ago
    Sold Out!
    45 mins
    Tutorial
    Beginner

    Everyone has acronyms, mnemonics, and a list of rules to guide their everyday software design. In order to get the most out of these age-old gems, one needs to deliberately practices them. Rules are a good way to remind ourselves of these gems.

    Corey Haines emphasies his design guidelines in form of the "4 Rules of Simple Design." Attend this talk to understand the four rules and their importance in everyday programming.

  • Liked Corey Haines
    keyboard_arrow_down

    Stories from 10 Years of Extreme Programming

    Corey Haines
    Corey Haines
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    10 years ago I was introduced to Extreme Programming. Since then, I've been an avid practitioner, applying the techniques and values to my life as a software developer. Over that time, I've bounced between many extremes, learning and reflecting on the value that I get when building systems both for myself and for others.

    In this talk, I'll share some of those learnings and how my life as a software developer has changed with the times.

  • Liked Tarang Baxi
    keyboard_arrow_down

    A Practical Guide to Setting up Distributed Agile Projects

    Tarang Baxi
    Tarang Baxi
    Chirag Doshi
    Chirag Doshi
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    A practical guide to setting up a new agile project team. Based on years of agile delivery and coaching experience for projects in a number of distributed and offshore models, for teams sized from 10 to 200 people, and spread across 4 continents, and 8+ locations. Some areas that will be touched on:

    • People - how to organize distributed teams, cultural factors to consider, ways to build trust, and how to avoid timezone burnout.
    • Process - how to communicate effectively, plan collaboratively, setup distributed practices (standups, retros, pairing, etc), effectively divide work on a common codebase, maintain visibility, and track progress.
    • Tools - (tips provided as a handout) which hardware and software tools should you absolutely invest in to help overcome communication,  visibility and collaboration challenges
  • Liked Mukesh Bhangria
    keyboard_arrow_down

    Continuous Refactoring at Amazon: A Case Study

    Mukesh Bhangria
    Mukesh Bhangria
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Between the project deadlines, we always feel there is code which needs to be improved

    Usually Developers have the following 3 options:

    - Bite the bullet and do the refactoring as they go along.
    - Park the issue and address it later.
    - Allocate special time when the project gets out-of-control.

    As customer facing stories take higher priority, usually Developers are forced to choose the last option.

    However a team at Amazon took a different approach. Attend this session to listen to their first-hand story of how they changed this typical behavior to achieve Continuous Deployment on a critical service.

  • Liked Victoria Schiffer
    keyboard_arrow_down

    Agile Coaching? Sure thing! What about Life Coaching in Agile Thinking?

    Victoria Schiffer
    Victoria Schiffer
    schedule 3 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

    Methodology Patterns: a Different Approach to Create a Methodology for Your Project

    Giovanni Asproni
    Giovanni Asproni
    schedule 3 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

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

    Naresh Jain
    Naresh Jain
    schedule 3 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.

  • Liked Daniel Zen
    keyboard_arrow_down

    Agile Engineering Javascript with Jasmine & AngularJS, Karma & Jenkins

    Daniel Zen
    Daniel Zen
    schedule 3 years ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    Agile & Test Driven Development of frontend JavaScript User Interface code is often passed over using the excuse that the UI code is "declarative" (What you see is what you get) and therefore does not 'need' to be tested. Others, will dismiss testing frontend AJAX code as too difficult to maintain or unnecessary because it is only important in context with the server. We will show how these misconceptions are false. 

    We will cover several popular JavaScript tools and technologies that make Agile frontend web development easy. We will show how these front end technologies cannot only be functionally tested, but Unit Tested. If time is available will cover Continuous Integration, Dependency Injection, & Mock objects.  

    By including your front-end code in your automated testing process you can prevent the inclusion of bugs that are usually only caught with manual testing.

  • Naresh Jain
    Naresh Jain
    schedule 3 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.

  • Bhavin Kamani
    Bhavin Kamani
    Abinav Munshi
    Abinav Munshi
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    Agile processes are the new order of IT implementations. These talk will elaborate on our experience and learnings during agile process implementation at Walmart. 

    We will touchupon following 3 key areas and our learnings that helped us scale agile in large enterprises.

    • Process Visualization - Our learnings related to visualization of existing processes and practices and how it helped us identify signals from noise

    • Product Backlog Elaboration - In a complex and large programs product backlog management and role of product owner needs to be revisited.

    • Team Working Agreement - This is particulary crucial for scaling agile as dependency management is one of the key aspects of enterpsie agile implementation.

    We will conclude with our key learning of how processes needs to be continuously evolved in large scale implementation.

  • Liked Pramod Sadalage
    keyboard_arrow_down

    Ten Patterns of Database Refactoring

    Pramod Sadalage
    Pramod Sadalage
    schedule 3 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 Johannes Brodwall
    keyboard_arrow_down

    Practice agile programming with coding dojo

    Johannes Brodwall
    Johannes Brodwall
    Buddhima w.wickramasinghe.
    Buddhima w.wickramasinghe.
    schedule 3 years ago
    Sold Out!
    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.
  • Johannes Brodwall
    Johannes Brodwall
    Niruka Ruhunage
    Niruka Ruhunage
    schedule 3 years ago
    Sold Out!
    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.

  • Liked Mikael Gislen
    keyboard_arrow_down

    Mitigating clashing paradigms between Agile Development and ISO 9000

    Mikael Gislen
    Mikael Gislen
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Advanced

    There are, on a philosophical level, significant clashes between the agile paradigm and Quality Systems such as ISO 9000 or CMM/CMMi, this is already presented in the Agile Manifesto. Agile Development is based on what I would call post-modern paradigms when compared to the plan-driven and early iterative development methodologies which are based on a positivist paradigm.

    The underlying philosophical challenges cannot be easily mitigated. But a purist agile paradigm may tend to stress a positivist paradigm as well and this can be dangerous since then agile would not be agile any longer.

    While it may not be possible to completely remove the challenges between agile and quality systems, it is possible to learn to live with some tension between different paradigms. 

    There are some obvious areas of conflict, for examplethe Agile methodologies strongly discourages unnecessary documentation, and questions that it is possible to provide all requirements up-front. ISO 9000 on the other hand demands requirements up-front and documented evidence of almost anything, but such practical aspects can actually be mitigated with relative ease. Other aspects may demand much more effort. In particular the internal auditing process is problematic and other means of ensuring compliance may have to be considered.

    We have in my company systematically piloted a number of organisational changes in order to better support agile development. We have done this within the overall framework of our ISO 9000 system which is used a structure anda a gatekeeper. To do this we have used Action Research, which in it self is a kind of agile methodology, although of much older date than agile development.

    I will in my talk focus on the practical experiences we have had of building an organisational framework for agile development and while doing that suggesting a few means to mitigate the challenges mentioned initialy.

  • Liked Sudipta Lahiri
    keyboard_arrow_down

    Capacity Planning for Dynamic Teams

    Sudipta Lahiri
    Sudipta Lahiri
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Fixed price (and fixed scope) projects dominate the offshore industry. These projects have offshore/onsite teams. They often have large team size (over 100s of people in one team).

    Agile thinking uses team velocity/ throughput and uses that to project an end date (Kanban system) or how much scope can be accomplished in a given time duration (number of sprints in SCRUM). They assume a stable team. However, this is not applicable for projects. They experience resource and productivity ramp-up issues. Often, resources keep changing as new projects come in. Projects do not have past velocity or throughput data. Extrapolating historical data from other similar projects, though possible, is inaccurate for multiple reasons.

    This talk is based on our experience of working with such project teams. They want to adopt agile methods. We show how they can adopt the Kanban Method and yet do: A) Initial Capacity Planning B) Assess the impact of scope creep to the project end date.

    The session assumes a basic understanding of the Kanban method.

  • Liked Evan Leybourn
    keyboard_arrow_down

    From Lean Startup to Agile Enterprise (beyond IT)

    Evan Leybourn
    Evan Leybourn
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Traditional models of management and corporate governance are failing to keep up with the needs of the modern economy. Change, both technological and cultural, is occurring at faster rates than ever before. In this climate, modern enterprises will live or die on their ability to adapt. This is where Agile, and Agile Business Management, come in. Agile is change; changing how you think, changing how you work and changing the way you interact. This is important whether you are a software developer or a CEO.

    In this presentation, Evan will provide engaging and enlightening case studies of Agile beyond IT; from lean startups to large enterprises. These will be reinforced with practical approaches for the leadership of teams, divisions and businesses. 

    Taking the successful concepts and methods from the Agile movement and Evan's new book, Agile Business Management is a framework for the day-to-day management of organisations regardless of industry, size or location. We will discuss processes, techniques, and case studies for the 4 key domains from Agile Business Management;

    1. You, the Agile Manager - What makes a good manager and how do their responsibilities change?
    2. Integrated Customer Engagement - Collaboration and communication techniques to build trust and deliver Customer needs efficiently, with minimal waste, and to everyone's satisfaction.
    3. The Structure of an Agile Organisation - Efficient, transparent and collaborative techniques to manage empowered staff.
    4. Work, the Agile Way - Managing all types of business functions, from software, HR, finance to legal, by using Just-In-Time planning and Incremental or Continuous Delivery processes.

    Ultimately, the goal of this presentation is to make you think about your role as a leader. 

  • Liked Ellen Grove
    keyboard_arrow_down

    Build Your Dreams: User Requirements Gathering with LEGO Serious Play

    Ellen Grove
    Ellen Grove
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    Let your hands be the search engine for your brain! LEGO® Serious Play® is a powerful thinking, communicating and problem solving technique that can help you and your team do serious work through structured play activities using a popular and playful 3D modeling toy. Through a facilitated process of building models that, storytelling and reflection, every person at the table is engaged and actively participating in the discussion, whether the topic is individual aspirations, team relationships, developing a new product or solving a wicked organizational problem. Everyone builds and everyone tells their story – all participants have equal opportunity to put their own points of view on the table, unlocking new perspectives and exposing the answers that are already in the room.  LEGO Serious Play has been used successfully for team-building and problem solving in a variety of organizations, from NASA to RBC to academic settings and public utilities.  

    This presentation provides a hands-on introduction to LEGO Serious Play, so that you can experience firsthand how using LEGO to do real work unleashes creativity and enables meaningful conversations in a very short time. We will explore how to use this playful technique to collaboratively elicit information about user requirements and strategic design issues using the open source User Requirements with Lego methodology developed by a team at the University of Lugano, Switzerland.  This approach is particularly suited to Agile teams that want to get team members and stakeholders sharing their different perspectives on common goals in an open and light-weight manner.

  • Liked Jason Yip
    keyboard_arrow_down

    Think Like an Agilist: Deliberate practice for Agile culture

    Jason Yip
    Jason Yip
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    If I say, culture is important to adopting Agile, most people will just agree without even thinking too much about it.  But what is meant by "culture"?  Why is it important?

    Culture is not typical behaviour; it is not what we say we value (but don't actually do).  Culture is our basic assumptions of how things work.  Culture is the logic we use to think through and respond to any particular situation.

    If you imagine a pyramid, Agile practice and any other visible behaviour is on the top, stated or written Agile values and principles are in the middle, fundamental assumptions (aka culture) is at the base.

    My session is intended to expose people to the base of that pyramid.

    If culture is assumptions, then to understand Agile culture, we need to understand the basic assumptions of Agile.  To do this, I have created an approach called "Think Like an Agilist" that both exposes how we think through an "Agile situation" and allows us to deliberately practice "Agile culture".

    The general idea is that I won't just talk about Agile culture and values, what I'll call "culture theatre", but rather expose people, who nominally consider themselves part of the Agile culture, to their underlying thought processes and assumptions, given a relatively difficult scenario.  Those thought processes and assumptions are the essence of culture (reference Edgar H. Schein).  What is interesting is noting when the thought processes and assumptions are different which indicates that there is a different culture at play.  What I've noticed is that this difference is common between novice vs expert Agilists.

    Note that it isn't even about analyzing vs doing it mechanically but more about exposing what assumptions are being used to respond.

    NOTE: I will be updating the attached slides as when I created them, I was framing it more as "doctrine" rather than "culture", defined as fundamental assumptions"

  • Aman King
    Aman King
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Are you an Agile Practitioner? Or are you responsible for Agile transformation?

    Organizations that have begun their Agile journey welcome the guidance of an experienced Agile Coach. But external guidance cannot continue indefinitely as the only way to scale Agile.

    If you are in an Agile team, are you prepared to take on the coaching role for other teams once your Agile Coach moves on?

    If you are a manager, are you looking at grooming in-house coaches to scale and self-sustain transformation?

    The transitioning of practitioners into coaches can be key to your Agile journey. Individuals get to build on their potential, while the organization becomes more self-reliant.

    This session explores my personal journey from practitioner to coach. It should help you too in taking that first jump into the role of a coach. I will share real-world examples of dealing with on-the-fly situations, and of preparing upfront where possible. I will recommend resources, and mention handy techniques that should be in a coach's toolkit. The session essentially provides a kick-start for first-time coaches.