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.

 
12 favorite thumb_down thumb_up 14 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

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

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

    Tarang Baxi - A Practical Guide to Setting up Distributed Agile Projects

    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 Bernd Schiffer
    keyboard_arrow_down

    Bernd Schiffer - Net Promoter System for Agile Companies

    45 mins
    Talk
    Intermediate

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

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

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

  • Liked Victoria Schiffer
    keyboard_arrow_down

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

    Victoria Schiffer
    Victoria Schiffer
    Agile Coach
    SEEK
    schedule 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 Naresh Jain
    keyboard_arrow_down

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

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 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.

  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    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.

  • 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 Sudipta Lahiri
    keyboard_arrow_down

    Sudipta Lahiri - Capacity Planning for Dynamic Teams

    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.

  • Aman King
    Aman King
    Agile Technologist
    ThoughtWorks
    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.

  • Liked Abhilash Chandran
    keyboard_arrow_down

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

    20 mins
    Experience Report
    Intermediate

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

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

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

    Why did we did this?

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

    Let’s complicate this further.

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

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

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

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

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

    My experience

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

  • Liked Sreerupa Sen
    keyboard_arrow_down

    Sreerupa Sen - Changing our Rhythm: Our Ongoing Journey towards Continuous Delivery

    Sreerupa Sen
    Sreerupa Sen
    Architect/Developer
    IBM
    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 Vinodhini
    keyboard_arrow_down

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

    20 mins
    Experience Report
    Intermediate

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

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

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

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

    The session will cover the following key areas:

    How such projects can be initiated

    - What type of team model and contract type we used

    - How we did the agile transformation with the customer

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

    - To improve remote collaboration the tools and techniques we used

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

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

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

  • Liked Andrea Heck
    keyboard_arrow_down

    Andrea Heck - Distributed Product Owner Team for an Agile Medical Development

    Andrea Heck
    Andrea Heck
    Agile Coach
    Siemens AG Healthcare
    schedule 3 years ago
    Sold Out!
    45 mins
    Case Study
    Advanced

    We are developing medical imaging and workflow software in an agile way with development teams distributed to several countries. One of the major challenges is how to set up and communicate within the Product Owner team. There we have to deal with the distribution, e.g., have the Product Owner either onsite with her peers or with her Scrum team, travelling, or with proxy. We need people who are good in two different fields of knowledge: medical and software development. As a third issues, the environment of the customers may be different in different countries.

    We have ramped up local Product Owners in different countries, have found local collaboration customers, and have developed a set of communication channels and workshops how to synchronize Product Owners in the team, share a common vision and backlog with their Scrum teams, and collaborate with customers locally and globally.

  • Liked Prasanna Vaste
    keyboard_arrow_down

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

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

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

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

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

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

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

  • Liked Anna Obukhova
    keyboard_arrow_down

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

    Anna Obukhova
    Anna Obukhova
    Agile Coach
    Luxoft
    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 Bernd Schiffer
    keyboard_arrow_down

    Bernd Schiffer - Inspire Management! From Status Quo to Awesome

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

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

    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.

  • Liked Neil Killick
    keyboard_arrow_down

    Neil Killick - The Guessing Game - Alternatives to Agile Estimation

    Neil Killick
    Neil Killick
    Lead Agile Coach
    MYOB
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Agile promotes empiricism and change, yet many practitioners continue to scope out and estimate delivery times and costs for software products and projects.

    Defenders of the art of estimation claim that we need to estimate software projects in order to answer common business and customer questions such as:

    • Should we go ahead with this project? (go/no-go)
    • How much will it cost? (bottom line)
    • When will it be done? (predictability)
    • Should we do project B instead of A? (prioritisation)

    This session challenges participants to flip these questions on their heads and seek alternatives to estimation rituals. It covers the many risks inherent with an estimation culture and demonstrates real, practical alternatives, both at the portfolio and the sprint level.

  • Liked Aruni Siriwardene
    keyboard_arrow_down

    Aruni Siriwardene - The Waterfall enthusiast and The Agile Contract

    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 Pradeepa Narayanaswamy
    keyboard_arrow_down

    Pradeepa Narayanaswamy - WORKSHOP- Defining Behaviors as a team

    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.

     

     

  • Liked Anuradha Gajanayaka
    keyboard_arrow_down

    Anuradha Gajanayaka - Some say they do Scrum to be agile ...

    45 mins
    Experience Report
    Intermediate

    In the challenging context of offshore Agile Software Development, not everything in the book would work. In this experience report, I would like to discuss how the teams can tailor the current so called standard Agile methodologies/practices (within the guidelines of the Agile Manifesto), yet become successful in deliveries.

    In the session, I would like to discuss some of the agile practices the audience is using and then discuss the challenges they face when it comes to Agile Offshore Development. Then I would like to draw my experience on offshore software development projects where we successfully used Agile concepts and demonstrate how to customize those standard methodologies/practices within the Agile Manifesto Framework.