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

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.

 
 

Outline/structure of the Session

The session is an interactive tutorial. I'll be explaining my ideas, and sharing my experiences, but the audience will be encouraged to interact, share their own experiences, and also challenge my point of view

The main points I'll touch, roughly, are the following:

  • The problem with "off-the-shelf" methodologies
  • Definitions of pattern and pattern language
  • An introduction to methodology patterns
  • Pattern languages for software methodologies
  • The advantages of using patterns and pattern languages
  • How to build a custom per-project methodology
  • How off-the-shelf methodologies can be described in terms of pattern languages
  • How off-the-shelf methodologies can still be useful
  • Sharing of my experiences with this approach, and some real world experience (positive or negative) from the audience

Learning Outcome

Attendees will learn the basics of how to create a methodology that fits the needs of their projects, and will get a better understanding of why some of the "pre-packaged" methodologies are (or may be) difficult to use in their contexts.

Target Audience

Everybody with a stake in a software project outcome

Requirements

I will need a projector for the slides, and a flipchart or a whiteboard.

No special requirements for seating arrangements.

Participants don't need to bring anything, but it would be useful if they came prepared with some examples, they may want to share, of good and bad experiences with methodology implementations in their teams, and with challenging questions for me.

schedule Submitted 3 years ago

Comments Subscribe to Comments

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

    I like the topic, but I think a few details need to be fleshed out.

    Is the proposal about making a case for why teams should mix and match patterns? Or is it about some specific patterns you have found and would be talking about them?

    If the proposal is just about making a case for mix and match, then the session would be useful, but limited. Many teams already mix and match to some degree. The trouble is identifying which mix is right for a given context.

    That's where I would like to see a collection of specific patterns that you've seen, the context's they are applicable in and how the patterns work together. That would be highly useful. I've gone through the resources you've linked in the proposal and haven't seen any specific patterns in any of them.

    There has been some work in the community on this, notably http://www.amazon.com/Organizational-Patterns-Agile-Software-Development/dp/0131467409 and http://www.scrumplop.org/ , but overall it has been limited. If this session builds on this with further patterns, then it would be an enthusiastic +1 from me.

    • Giovanni Asproni
      By Giovanni Asproni  ~  3 years ago
      reply Reply

      Hi Siddhi,

      I answered many of your questions in my reply to Jerry Rajamoney two weeks ago (look a few replies below this one). I'll try to summarise some of those things up here for you.

      I'm not simply advocating mix and match (which, as you rightly pointed out, many teams do anyway), what I'm trying to achieve is a bit different:

      - Describing the various practices as patterns we can describe when they work best and when they don't. Many teams mix and match practices haphazardly without considering the pros and cons of each. Furthermore, creating pattern languages that connect those patterns together will show which practices work well (or don't work) together, giving people a roadmap to individuate which mix is the right one for a particular context. Note that many patterns will actually belong to several pattern languages

      - I think we need to fundamentally change the conversation about methodologies--which, in my opinion is too focused in the unachievable goal of finding the one that will work for every context

      You mentioned Jim Coplien's book (the organizational patterns one), which I actually mention in my talk. I think it represents a great start, but I fully agree with you that is not enough. There is much more to be done, and we also need to look outside the software world for some patterns, e.g., the management literature.

      I will show some patterns and pattern languages in the talk, but the real intent is not to present a full set of patterns and pattern languages (in fact that would be quite challenging, to use an understatement), it is instead to start convincing people to look at methodologies from a different angle, which, in my opinion, is actually a more useful one than deciding if to use Scrum, Kanban, Scrumban, Waterfall, or anything else.

      I'm also in the process to start some kind of wiki or other collaboration tool (I haven't decided yet) to start getting contributions from the community, and hopefully get some help, as it is quite a big endeavour.

      I hope I've managed to make some things a bit clearer.

      Regards,

      Giovanni

       

  • Prasad
    By Prasad  ~  3 years ago
    reply Reply

     

    I like this, have you thought about how the a custom methodology is going to behave in based on the phase of stage in which the product / application ( early stage, growing stage, stable, decline, lights on etc..)

    ~ Prasad

     

    • Giovanni Asproni
      By Giovanni Asproni  ~  3 years ago
      reply Reply

      Hi Prasad,

      The beauty of the approach I'm proposing is that how the different phases of a project are handled is entirely up to the project stakeholders. Different companies have very different ways of doing things, and by creating a methodology with the approach I suggest, they can come up with something that really suits their needs. Also, as I see it, a methodology is a "living" thing, therefore it can (and will have to) change with the change of the surrounding context (which may well be a change of project phase).

      Of course, there is a strong need for discipline and common sense to avoid falling into the trap of hacking as usual.

      I hope this answers your question.

      Regards,

      Giovanni

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

    Hi,

    After looking at the presentation and the answers I am more curious to know in detail about this topic. At the same time could you kindly explain more on my query mentioned below?

    In one of the response you have mentioned you will mix and match Practices (engineering). This is great and many teams are already following that. Do you believe folllwing engineering practices alone will give a whole picture? If I want to create a complete "New methodology" for my "project" as a whole, don't we need to go beyond these practices? Do you suggest something for those to get a 360 view of the "newly created methodology?" Are you planning to cover these touch points in your presentations to get more value?

    Thanks for your time

    Jerry

    • Giovanni Asproni
      By Giovanni Asproni  ~  3 years ago
      reply Reply

      Hi Jerry,

      With "practices" I mean all of them, including engineering, management, leadership, etc. I have used engineering ones just as an example. In fact, I believe that any working methodology has to focus in all relevant practices.

      The rest of the answer is quite long, but I hope it will make my position clearer.

      My preferred definition of methodology comes from Alistair Cockburn's "Agile Development" book:

      Your ”methodology“ is everything you regularly do to get your software out. It includes who you hire, what you hire them for, how they work together, what they produce, and how they share. It is the combined job descriptions, procedures, and conventions of everyone on your team. It is the product of your particular ecosystem and is therefore a unique construction of your organization.

      As you can see, the definition above is much broader that what you get with Scrum, Kanban, etc. In fact, to be precise, methodologies like Scrum and Kanban, Waterfall, etc., are methodology frameworks, as they put some constraints in what you are supposed to do, but leave many (very important) details to the specific implementations. Your methodology has to take care of all those details.

      In my talk I suggest to mine for patterns by looking not only at the technical literature, but also at the management literature (e.g., Harvard Business Review, MIT Sloan Management Review, etc.), and any other relevant field that can give us useful information about what we can do. Furthermore, I strongly believe that the methodology doesn't belong to development team(s) only, but also to the other people that have to interact with those teams. As a case in point, the methodology has to be agreed also with the users and customers who have the right to know what to expect, and also have needs and constraints that the development teams have to respect. I've seen far too often teams deciding on implementing a methodology and imposing it on their customers only to cause malcontent and friction.

      One more thing to notice is that there are practices that cannot really be classified as "technical", "managerial", or something else, because they are actually all of them--think of pair programming, it has both strong technical and managerial implications, so putting it in only one of those categories would be a big mistake as it would let you forget of many of the implications of using it. 

      Patterns and pattern languages is, in my opinion, are very useful tools (more useful than pre-packaged methodology frameworks) to help us create an appropriate methodology for our projects for various reasons, including:

      1) Describing a practice as a pattern means that we describe not only the positive effects, but also the  contexts in which it is known to work best, and the costs of using it. The contexts and the costs are particularly important because are what determine the success or the failure of a practice in a particular project, and are the things that are very rarely discussed by the proponents of a particular methodology framework.

      2) Pattern languages give an indication of which patterns work well or not so well with each other, so they can be used to make some informed decisions on what to try in a particular project. Also, knowing that a particular pattern you may want to use belongs to several pattern languages (e.g., technical and managerial) will help you in understanding better all the implications of using it. Again, pre-packaged methodology frameworks tend to present practices as belonging to only one category leading people (especially beginners, but also some "experts") to ignore several other implications.

      3) Freeing the mind from thinking in terms of Scrum, Kanban, Waterfall, etc., and starting to think instead of what is really important for the project removes the fear of doing something bad because we are not following the methodology by the book, as there is no sacred book anymore. Believe it or not, I've met quite a few teams that felt almost ashamed because they were doing Scrum but not quite, and forgetting that if it is working for them, they shouldn't care.

      There is more (after all I'm asking for a 90 mins slot), and there are complications as well which I will talk about if the session is accepted. In the meantime, I hope the explanation above is sufficient to give you a fair idea of the main concepts I'd like to talk about.

      Apologies for the length of the reply.

      Giovanni

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

        Hi Giovanni,

        Thanks for the detailed reply. Actually the reply was bigger than your proposal :). You nailed down my doubt in the last para "Freeing the mind from ...". I often hear from CST's "To be Agile do scrum". You are saying to BE Agile do whatever works for you rather focussing on Scrum / Kanban / etc.. Great point

        All the best for your proposal.

        Thanks,

        Jerry

         

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

    Hi Giovanni - I went through your slides and felt while it was a good discussion topic, it didn't offer any specific example of what you and why you did, and what were the results thereof. It will be great to understand how exactly you went about picking up various practices and what did you learn in that process. Would you want to put up a strawman deck on this so that the reviewer panel could understand the topic better?

    -TV

    • Giovanni Asproni
      By Giovanni Asproni  ~  3 years ago
      reply Reply

      Hi,

      It is work in progress, and I haven't written a lot of detail yet. I'll put up a strawman deck as you require, by when do you need it?

      Thanks,

      Giovanni

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

    Hi Giovanni,

        I think mix-and-match are what most teams do in practice. Is the talk more along the lines of how best to mix and match?  Or is it more focused on making the case for performing mix and match?

    • Giovanni Asproni
      By Giovanni Asproni  ~  3 years ago
      reply Reply

      Hi Ted,

      There is a bit of both, but the talk will be more focused on an approach on how to best mix and match--patterns and pattern language can provide the necessary amount of information to do that.

      I will make the case for performing mix and match because, even if many teams do it in practice, many of them seem to be afraid to admit that and feel the need to call it Scrum, Kanban, Waterfall, etc. This is unnecessary. If the approach works, who cares what is called?

      Also, part of the case for performing mix and match is that the effectiveness of a single practice in a certain context can be measured empirically without too much trouble, but measuring if a methodology in its entirety is better than another one in a certain context cannot really be done in practice. Think of the debate Scrum vs Kanban found in many places, that is completely pointless in my opinion.

  • Savita Pahuja
    By Savita Pahuja  ~  3 years ago
    reply Reply

    Hi Giovanni

    I think all the participants would not know about all the methodologies available in the market plus mix and match depends on nature of project. could you please provide more information how you are deriving mix and match. Do you have any case study or have you ever implemented this.

    On the organization level we dont rely on one. So implementing Scrum, XP , Kanban , lean together is a common practice. How yours session is different ??

    Regards

    Savita

    • Giovanni Asproni
      By Giovanni Asproni  ~  3 years ago
      reply Reply

       

      Hi Savita,

      Thanks for your comments.

      First of all, I do not mean mix and match of methodologies (e.g, Scrum + Kanban), but mix and match of practices (e.g., TDD + Pair Programming + Configuration Management, etc.) to create your own methodology per project--the most effective teams I've seen, don't do Scrum, Kanban, or any other named methodology, but they do their own thing, by choosing the practices they want to adopt according to their contexts. This is an approach I regularly follow with my clients, and I've published an experience report some time ago "An Experience Report on Implementing a Custom Agile Methodology on a C++/Python Project" (but, at the time I wasn't thinking explicitly in terms of describing the practices as patterns).

      A big advantage of describing practices as patterns is that the pros and cons of each practice can be described easily--e.g., TDD is a very good practice to produce high quality code, however a con is that it requires a high level of expertise to be used proficently. Another example is self organization, which could be very good, but it works only in the right contexts. Many teams realize those problems only after big failures. Having that knowledge in advance would help them to take the appropriate action (like training, coaching, etc.) beforehand.

      Connecting the above patterns in pattern languages helps in clarifying which practices work well (or not so well) together and gives a path to follow to create an appropriate methodology for the project--and evolve it as the context changes.

      With the approach I'm proposing, there would still be a place for methodologies like Scrum, Kanban, etc. They could be used as starting points to overcome the blank page syndrome when implementing the new methodology--pick the one that most closely matches the context of your project and add and remove practices as necessary.

      I'm not claiming having invented anything new (experts may find what I wrote "obvious", such is the nature of patterns), also, a very good start for this approach has been described by Jim Coplien and Neil Harrison in their book "Organizational Patterns of Agile Software Development".

      Obviously, the approach is not trivial and there are several complications (which I will talk about in my presentation if accepted), but I hope I've given you a better idea of what I'm proposing.

      Regards,

      Giovanni

       

      • Giovanni Asproni
        By Giovanni Asproni  ~  3 years ago
        reply Reply

        I edited my previous comment to remove:

        "From the number of dislikes I received, and your questions, it is obvious to me that I need to update the proposal to make it clearer (I'll do it in the next couple of days)."

        Because I had misunderstood how the like-dislike widget worked and assumed I had several dislikes when it wasn't the case.


  • 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 Archana Joshi
    keyboard_arrow_down

    Applying Agile Principles in Primary School Education: An experience

    Archana Joshi
    Archana Joshi
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    An important issue that has plagued the Indian sub-continent is that of education and more importantly primary education. Since past few months, my weekends are usually occupied in teaching English classes to underprivileged children from 5th grade at a government primary school. As an Agile coach and a practitioner I was drawn towards unifying the concepts of Agile to help increase the quality of education.

     

    As a teacher, I was given a set of high level goal by the school administrator that needs to be accomplished every quarter. My goals for the first quarter were :

    • > Kids should be able to identify basic words
    • > Form short sentences.
    • > Converse reasonably in English

     

    I started with the traditional chalk and blackboard style of teaching focusing on the spellings, grammar, sentences, reading and so on. In initial few sessions, I quickly realized that it took too long for the kids to understand and so was not yielding the desired results. Some of the problems were like

    • > Too much focus on semantics and grammar
    • > Kids not opening up in the class room
    • > Only able to read words but not talk or frame sentences

     

    This is where I had to reflect and consider course correction in my style of teaching and Agile came to my rescue. This is a talk which highlights how Agile techniques were applied in teaching kids effectively.

     

     

  • Liked Abhilash Chandran
    keyboard_arrow_down

    Retrospectives with large projects and (or) multiple teams

    Abhilash Chandran
    Abhilash Chandran
    schedule 3 years ago
    Sold Out!
    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 Bernd Schiffer
    keyboard_arrow_down

    Net Promoter System for Agile Companies

    Bernd Schiffer
    Bernd Schiffer
    schedule 3 years ago
    Sold Out!
    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 Bernd Schiffer
    keyboard_arrow_down

    Inspire Management! From Status Quo to Awesome

    Bernd Schiffer
    Bernd Schiffer
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    One of the most rewarding change opportunities for organization to create awesome workplaces exists by being innovative at the management level. Forget step-by-step explanations of management practices (you can’t copy culture!); the key to address the management level - i.e. to foster innovations at this level - is by inspirations. In order to get an awesome workplace, you have to see awesome workplaces. There are plenty of ways to inspire people, but this opportunity is often wasted during the introduction of Scrum and Kanban methods, or never reflected upon afterwards.

    In this session, I will show you several aspects of awesome workplaces. A constantly growing container for inspiring management are the Agile Management Innovations (AMI). AMIs are practices for management which lead to democracy, fairness, decentralisation, dialogue, and lot of other positive effects. These effects lead to awesome workplaces, where people are truly motivated. The idea behind inspiration is to foster creativity and innovation through a changed environment. Management practices can't be just applied; 50% of management practices depend upon the organisation's culture. That's why we call them AMInnovations.

    If you experiment with AMIs, you'll get from status quo to awesome (that is of course only when you're status quo is not already awesomeness).

    I’ll introduce the concept of AMI as well as plenty of real world examples. The goal is to inspire you twofold: I will inspire you in this session to experiment with AMIs, and AMIs will inspire the people within your organisation to achieve a better workplace.

  • 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 Sreerupa Sen
    keyboard_arrow_down

    Changing our Rhythm: Our Ongoing Journey towards Continuous Delivery

    Sreerupa Sen
    Sreerupa Sen
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Annual software release cycles cramping the agility of the team? Too many hot fixes reducing the efficiency of your organization? Customers waiting impatientlyfor  the next cool features hot off the press? These are some of the painful and common problems faced by development teams worldwide. In today's world, most things get outdated or out-of-fashion very fast - and software is no different. Users cannot afford to wait for the next cool set of features for a year. They want a steady stream of cool new features that they can adopt and use immediately.

    My team follows a development model that we like to call Open Commercial Development - where we're always connected to our stakeholders, our plans are out in the open, and we're always gathering feedback and reprioritizing. We used to have yearly releases of our product - a sort of big bang release with a host of new featres. Based on our stakeholder interactions, however, we figured that our software delivery wasn't agile enough for our customers. Users wanted new features incrementally throughout the year. They especially didn't want to wait a year for a feature that they'd requested that was critical for their business.

    So began our journey to Continuous Delivery - an interesting one for sure. It's not easy to deliver new features, manage technical debt, collaborate with users and incorporate their feedback into the new features - once every quarter. To do it consistently, with quality and on time, you need to have a framework in place - a combination of planning, process, automation and team organization - that lets teams focus on the right things to get to DONE DONE for their new features, and at the same time manage their quality and tecnical debt. Over the past year, we like to think that we've put that framework in place, and that is what I'd like to talk about in this session.

  • Liked Avinash Rao
    keyboard_arrow_down

    Planning For and Delivering Quality in Large Scale Enterprise Agile Development

    Avinash Rao
    Avinash Rao
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Advanced

    Success in large enterprise software development depends on delivering capability and Qualities as much as functionality. In larger programs, given that Agile makes it easy to develop functionality quickly, building Qualities like performance and resilience in enterprise Agile needs deliberate and focused effort and planning. 

    Traditionally, Agile development tended to be smaller, contained (geographically as well as in size), allowing for Quality to be in built and monitored every iteration in the delivery of Agile projects. As Agile goes mainstream and more enterprise programs and IT development is Agile, more attention needs to be paid to the –ilities that will determine success or failure in the Enterprise. 

    Based on experiences from a geographically distributed, multi-year, multi-vendor 30+ million USD Agile product development that the author program manages, this session highlights the vulnerable areas that impact Agile Quality in large enterprise programs:

    -          'We'll figure it out as we go along' Architecture;

    -          Evolution in corporate security and IT governance guidelines;

    -          The Agency problem between the needs of the business and the representatives of the business;

    -          The temptation to build functionality quickly to demonstrate progress.

    For each area of vulnerability, the session will provide guidance and ways and means to manage the risk of lowered Quality.

  • Liked Archana Joshi
    keyboard_arrow_down

    How do I know if Agile is working for me or not? – An Executive’s Dilemma

    Archana Joshi
    Archana Joshi
    Sheshadri Shekhar
    Sheshadri Shekhar
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    As Agile coaches, several times when we talk to the Sr. Management in a company to taking agile to a bigger level and adopt it across their business units a common response we get is "I have seen agile working for our project teams. I am also in midst of an agile transformation where we are applying it in large programs. But how do I know the transformation is helping me achieve my goals at an organizational level. Our organization typically tracks executives on finance, people & delivery parameters. In an agile context, how do I ensure that I am on track with the executive-level dashboard (finance, people and delivery)?" As part of this session, we plan to share our experience of how "Balance Score Card" technique was implemented at one of the financial services company following agile. By using concept of balance score card we were able to map the agile goals with the IT organization goals and ensure that the agile methods were giving the desired results.

  • Anushya Prasad
    Anushya Prasad
    schedule 3 years ago
    Sold Out!
    20 mins
    Case Study
    Beginner

    Ever watched a pair of cooks on Master Chef working in teams, an open kitchen in a restaurant or Gordon Ramsay yelling across the kitchen at his team of chefs?

    Ring a bell? Doesn't it remind you of your project team? Or if you're a foodie like me, of the similarities between a software project, your team and a Gourmet kitchen? Is there something we can learn from them?

    This talk is an attempt to draw such a comparison highlighting how our teams and a bunch of chefs in a restaurant kitchen function to whip up something so delectable that our customers want to come back for seconds. 

  • 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 Vibhu Srinivasan
    keyboard_arrow_down

    Coding with Geeks- De Code the secrets behind TDD, BDD and ATDD

    Vibhu Srinivasan
    Vibhu Srinivasan
    schedule 3 years ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    This session is a coding sessiont that takes a problem and shows clearly what is the difference between TDD, ATDD and BDD. Ths session uses code for the server layer as well as UI layer.

    This session is not for you if you do not code. If you do code, please bring your laptop as we delve into the details of all these styles of programming techniques.

    We will rotate between ATTD, TDD and BDD periodically and show it at use in different layers. This session will be using Java , Rails, Scala and C# together so that you can see how you can benefit do these techniques even when coding in different languages.

    We look at common pitfalls and wrong beliefs that programmers have when it comes to these concepts

    This session is purely keyboard and you will have to bring a laptop.

  • Aruni Siriwardene
    Aruni Siriwardene
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    A traditional software development project entails specifics around elements in or out of scope, tied up to deliverables, all ensconced within specified estimates and timelines, subjected to legal clauses for everything from acceptance to indemnities. For Agile contracts, the boundaries of legal intervention must stand; merely due to the marriage of parties when a project is executed; the definitions of boundaries must be established be it scope, budget or timeline and all standard deliverables from a traditional project stands; yet, the execution is as diverse as chalk and cheese.

    What are the key criteria to be aware of when we define Agile contracts; as in typical agile projects, should the client be involved in mutually drafting the contract? How much legal intervention can we allow? What happens to deliverables and expenses when delays occur and scope boundaries are reduced? Can blame be apportioned to an extent that each party will have to indemnify themselves?

    An Agile contract needs to reflect the nature of the engagement; no template contract with standard clauses can be coaxed upon a true agile project. In line with the Agile principles and values and targeted to the agile manifesto; Agile contracts should be just that – Agile!

  • Liked Abhilash Chandran
    keyboard_arrow_down

    Agile Appraisal: Sprint Iterations for Appraisal reviews

    Abhilash Chandran
    Abhilash Chandran
    schedule 3 years ago
    Sold Out!
    45 mins
    Case Study
    Beginner

    Appraisal reviews are always hard. Traditionally it is done once a year. The manager and employee undergo a tough period of reviews, discussions and ratings. At the end no one is happy.

    • Manager
      • Manager is forced to provide a feedback of an entire year in few minutes.  
      • Because of time constraints and lack of useful data, a constrictive feedback is not given.
      • In most of cases this ceremony is reduced to mere salary negotiations.
    • Employee
      • Employee feels cheated because of lack of any concrete feedback
      • Employee is not able to proactively discuss his/her career objectives and create a proper plan to bridge the talent gap.

    In this talk I will discuss some of the approach we are trying to follow in our group to align appraisal feedback also along with agile sprints.  

    I will present the experience report of how we are converting the age old waterfall appraisal process to Agile. I will discuss the need for this change, the general idea and the challenges we are facing.

    In this new way of appraisal management the focus is on the individual. Just like we have a Scrum/Kanban board, each employee will have a talent and improvement board. Instead of developing a product, the focus is to develop an individual. Like the scrum there are Ceremonies

    • Release planning – Organizational agenda
      • Decide Group & team goals
    • Sprint planning
      • Work with each team members to identify some “traits”/action points to improve
    • Review
      • Review the outcome
    • Retrospective
      • Based on the outcome revisit the individual goal & do a re-planning
  • 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.

  • Aruna Rajapaksha
    Aruna Rajapaksha
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Pair testing with onshore team members enrich the quality outcome and naturally transfer the domain knowledge to offshore teams effortlessly. This practice helps to sustain clients by providing superior quality outcome for their investments.

    Best practices of distributed testing, modern tools and technologies for communication, mitigating cultural gaps, language barriers and time zone differences are subjects itself to discuss in detail.

  • Liked Johannes Brodwall
    keyboard_arrow_down

    Kicking off agile remote teams

    Johannes Brodwall
    Johannes Brodwall
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    So your project is just getting started. Or maybe you're just about to embark on a new release. Or new members just joined the team. What now?

    In either situation, your project will have a lot of energy and attention right now. But at the same time, there's probably a lot of uncertainty about what to do first. Many projects waste this valuable time without a clear plan or purpose. In Exilesoft, we have refined activities to deal with these problems, even with the additional constraint that the team may be distributed geographically.

    In this workshop, we share a typical plan of what activities to do every day in the first weeks together with a set of activities which yeld tangible results in terms of team building, vision, architecture and a coherent working system in a minimum of time. Participants will get a chance to practice the skills as well with several interactive exercises.

  • 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 Anna Obukhova
    keyboard_arrow_down

    The SCRUM and the willpower: how neuroscience can boost your productivity

    Anna Obukhova
    Anna Obukhova
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Willpower is the force that is between the brain activity (I want to do this or I need to do this) and the action itself (start coding). If there is not enough willpower, people find it difficult to start any activity (especially that involves
    decision making).


    What is the standard approach when you feel tired and find it difficult to concentrate? Take some coffee (but latest research shows that coffee depletes the brain activity, even when body has more energy), take some sweets (but sugar ends quickly and gives even more exhaustion to the body)? These widely used strategies generally do not work, and in long-term even add harm to the body and brain.


    The willpower is not endless (so-called muscle theory of willpower), it can be saved, it can be trained, there are approaches how to keep the willpower level high. To keep the willpower (and thus, productivity) on the high level, people should know and use different approaches that lay in the field on the social and cognitive science.


    There are a lot of evidences that SCRUM improves the developer’s productivity in terms of speed of development, code quality, and accuracy of design. Unfortunately mainly all recommendations from SCRUM coaches look like “believe me, if you do this, you will have better velocity”. Yes, it works. But why does it work?


    Sometimes SCRUM does not give such great results even when main elements are in place. The question “Why” and “What makes the difference” is here again.


    I will describe the model of relationship between the willpower related brain metabolism on very low level (specific amino acid cycle) and the SCRUM practices. I can prove that SCRUM addresses the productivity of the people’s brain using 3 different flows simultaneously. There are several tips that make these productivity flows working or not. You can make Agile productive, you can have non-productive Agile. I will show you where the difference is.


    Overall there are 10 productivity tips that can be put into 3 flows.


    As the outcome of this session, Agile coaches, and all people who can change the process (in fact that is any team member) will review their SCRUM: does the way they have it improve the productivity or they are losing all the power? The changes are cheap, the outcome can be huge.

  • Liked Pradeepa Narayanaswamy
    keyboard_arrow_down

    WORKSHOP- Defining Behaviors as a team

    Pradeepa Narayanaswamy
    Pradeepa Narayanaswamy
    schedule 3 years ago
    Sold Out!
    45 mins
    Workshop
    Intermediate

    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.