In BetterConf, we have a feature which allows participants (or anyone for that matter) to select which sessions they plan to attend, create a custom URL and share it with their network.

Step 1: You visit the conference schedule.

Step 2: Click on the “Attend” icon to select a specific session.

If you want to de-select the session now, click on the “Skip” button. Also you’ll notice that on the top right hand corner, “My Schedule” shows (1) indicating that you have added 1 session to your schedule.

Step 3: Like this you can go through the program and select all the sessions you are interested in attending. Alternatively, based on your role, we’ve created a list of recommended sessions.

Once you select any role, the respective session will be highlighted, while the rest of them will be grayed out.

Now, you could skip some sessions and add some other sessions.

Step 4: Once you’ve selected all your sessions, you can select “Share” from the “My Schedule” drop down.

Selecting “Share” will bring up:

Note that we’ve generated an unique, short-url for you.

Step 5: Share this link on Twitter, Facebook or GooglePlus

or

Please make sure you keep the #AgileIndia2013 hashtag.

Jeff Patton, a.k.a Father of Agile-UX, is doing the most innovative work around product discovery, release planning, agile interaction design, and putting requirements into context. Jeff won the Gordon Pask Award in the year 2007, for his work helping establish what User-Centered Design means in Agile.

Jeff brings two decades of experience from a wide variety of products from on-line aircraft parts ordering to electronic medical records to help organizations improve the way they work. Where many development processes focus on delivery speed and efficiency, Jeff balances those concerns with the need for building products that deliver exceptional value and marketplace success.

We are thrilled to offer Jeff’s exceptional Passionate ProductOwner (CSPO) workshop at the Agile India 2013 Conference.

Recently, we caught up with Jeff and asked him the following questions:

Why the passion in product ownership?

First off, “Passionate Product Ownership” is a stupid title, because you can’t teach someone passion! However, I’ve always been involved in Product Development and Product Management, and I take the greatest pride from knowing that I’ve made a product or put something out into the world that other people use. The class focuses on understanding the business problems we are solving – the people who will use the product and understanding what their problems are. While I can’t teach passion, we can certainly focus on helping everyone understand that they are building products that help people, and that’s where the passion comes from.

The product ownership role is often defined as one of the most challenging roles defined in scrum, why is this?

Scrum and Agile processes in general, offer a lot of tactical guidance for how to get software built. But most Agile processes depends on getting the right person in the Product Ownership role – someone who already knows what to build.

This role difficult because you are responsible for building the right thing, and you are also responsible for communicating what that right thing is to a large group of people, sometimes in excruciating detail! In this class, one of the first things you’ll learn is that while there may be a single Product Owner who acts as a leader, product ownership is handled by a team of people. I’d rather that the role of Product Owner was named “Product Leader” and that whole teams take ownership. If you survive the class and adopt this way of thinking, you’ll be practicing a type of product ownership where everyone is involved in figuring out the details of what to do, who the user is, how best to help them and what solutions should be built and described in detail.

You’ve done significant work in blending UX & Agile. Where do you think the community is headed as far as UX on Agile projects go?

That’s a great question! It depends on which community you’re talking about. In the early 2000s, I spent a lot of time in the Agile community trying to help them understand what user experience was and its importance. Simultaneously, I spent time with User Experience people trying to help them not be so darn afraid of Agile Development as if it was going to “wreck” things.

I’ve seen a lot of maturation over the last decade and many UX people now have experience working inside Agile projects and teams. The coolest thing that’s happened within the User Experience community is that they have learned to change their practice so it works better in an Agile context. I’ve also seen more and more organizations working with Agile development recognizing the importance of understanding users and building products that people like. Organizations see that UX is the kind of work that happens outside the code and it isn’t an “engineering thing.” Currently, I am seeing the User Experience community going deeper and evolving practices that work better. For example, you’ll find books on Agile User Experience and Lean User Experience. Also more and more people who teach Agile practices acknowledge, or at least understand, what a user experience person does, although some challenges remain.

A new kind of Agile is forming, where the work that UX people do to understand users, prototype and try out ideas, is now called Lean Start-Up. A friend of mine, Leah Buley, once said, “Design isn’t a product that designers produce. Design is a process that designers facilitate.” The communities are starting to understand that the user experience work is cross-cutting and the concern is threading it’s way into everyone’s process.

What will be the key take away for the workshop attendees?

You will learn the practices that support the “Product Discovery” process and how to do discovery well. Building the right product is about understanding who the product is for and how they are going to benefit from using it. This is not a singular person’s responsibility – it is the whole team’s responsibility. The practices you’ll get in the class that support this come from user experience. Practices such as simple personas and story mapping provide understanding of users and model user behaviors. You’ll also get practices for good project management. For example, focusing product releases on specific target users, tactically guiding releases, ways to slice stories thinly to slowly build up a product, so that as soon as possible, it is a shippable, complete product. You’ll also gain practices for building small amounts of product as experiments to really validate if you are building the right product.

Limited seats are available for Jeff’s Product Ownership workshop. Book your seat today to avoid disappointment: http://booking.agilefaqs.com

Lasse Koskela will be presenting a workshop on ‘Test Driven Development Applied’ at Agile India 2013. He works as a coach, trainer, consultant and programmer, spending his days helping clients and colleagues at Reaktor create successful software products.

Lasse is also the author of books ‘Practical TDD and Acceptance TDD for Java Developers’ and ‘Effective Unit Testing’.

He is one of the pioneers of the Finnish agile community and speaks frequently at international conferences. He recently spoke at Agile2012.

We interviewed Lasse recently and asked him several questions related to one of his favourite topics TDD (Test Driven Development).

What are the mindset changes required by the developer(s) and team members when adopting TDD?

That would likely depend on the developer but I’d say that most often the biggest change required in one’s mindset is to acknowledge that you don’t know everything.

The more experience a programmer has the more likely they are to think of themselves as being “good”. A little confidence can be a huge boon to productivity but too much confidence creates blind spots–we literally learn to not question our assumptions and end up repeating the same old solution even if it’s not a very good fit.

TDD, on the other hand, makes us state some of those assumptions–such as what would be a good design for this class–in such concrete terms that it’s difficult to ignore the awkwardness when the same old solution doesn’t quite fit. It doesn’t fit and you can feel it through the difficulty you’re having writing a test for that design. Sometimes, you look at your test and go, “that doesn’t make any sense–much easier would be to…” And you end up changing the design.

How does TDD help developers in improving the art of software craftsmanship?

The process of programming test-first where you begin by expressing your intent from an automated unit test’s perspective has an almost magical effect on the kind of code you write. It’s much harder to write the kind of monolithic code we’ve all come to hate so much because the process of test-code-refactor invites you to create small, composable classes with clear responsibilities.

What I’ve also found is that TDD tends to help programmers learn what object-oriented design really means. It’s not just about encapsulating your code into “classes” but it’s about putting cohesive behavior into those classes. I wouldn’t go as far as saying that TDD makes you write object-oriented code but it certainly helps. I would say, however, that the better you understand object-oriented design the more comfortable you’ll likely feel test-driving code.

TDD is often perceived as slow, how does one justify the costs and benefits of TDD?

I haven’t heard that particular comment in a while but there certainly are a lot of skeptics when it comes to TDD. I guess every significant programming technique will have some skeptics. Skepticism is not a bad thing per se. In reasonable amounts a little skepticism is a healthy thing to have. That’s why I don’t try to persuade people to believe that TDD is good for them. I might believe but that doesn’t matter much. What matters is whether they themselves have an aspiration for becoming better. If you have that aspiration, perhaps you’ll give TDD a try and see for yourself.

With that said, there has been quite a lot of research into TDD–much more than around most other agile engineering practices–and that research seems to support the notion that TDD is a viable method for developing software. Research done at IBM and Microsoft, for instance, has measured that TDD (compared to a test-last approach) reduced defect densities by 40-90% while the management estimated that it added 15-35% to the time to implement a feature. The management had also concluded that the cost was far outweighed by the time and cost savings created by the reduction of defects.

I will repeat, however, that I don’t want you to take my word for it–or the researchers’ for that matter (especially without reading the research papers yourself). Instead, I’d like people to accept the possibility that they may or may not experience those reported advantages. If they decide to give it a try, even better. If they don’t, I hope they’re giving some other new technique a try. The absolute worst outcome would be that we stagnate at the status quo and stop improving on our profession.

What will be the key take away for the workshop attendees?

For first-timers the key take away is absolutely the first-hand experience of test-driving code. For people who’ve already dipped their feet into the water, I would expect them to walk out with the realization that their style of programming test-first is just one of many–some of which they’ve seen applied in the workshop–and with a resolution to try something slightly different when they get back to work. That’s something I am hoping to take away myself, too!

Seats for Lasse’s workshop are limited so book soon to avoid disappointment: http://booking.agilefaqs.com

I’m pretty happy to see the kind of response we’ve got world-wide for the Agile India 2013 Conference. Following is a graph which shows you the viewer’s from different parts of the world interested in Agile India 2013 Conference.

And from India:

Even though we have 3 more months for the Agile India 2013 conference, the registrations this time has been crazy. But how crazy is really the registration compared to Agile India 2012 Conference?

So I pulled out the stats and looked at the trend graph of what it look for 2012 vs. 2013.

Following is the comparison:

Yes, as you can see, we are off to a flying start (registration openned almost 3 weeks ahead) and  the Agile India 2013 conference is almost 2 weeks later compared to Agile India 2012 conference.

Over 558 delegates have registered for the Agile India 2013 Conference so far.

We’re happy to announce that we’ve participants from over 56 companies participating in the conference:

And they play the following 70 distinct roles:

1. How do you sustain growth over time with a steady stream of new disruptive businesses? Attend Mary and Tom Poppendieck’s full day workshop on The Fastest Learner Wins http://bit.ly/RDCzvr (Special Interview – http://bit.ly/Rvyhnz)

2. Can good architecture just emerge miraculously from a succession of iterations? Attend Kevlin Henney’s half-day workshop on Architecture with Agility http://bit.ly/RDCB6t (Special Interview – http://bit.ly/SzHOJz)

3. What can cognitive science teach us about becoming better thinkers, better problem-solvers, and better influencers? Attend Linda Rising’s full day workshop on Problem-Solving and Decision-Making in Software Development http://bit.ly/RDCDLI (Special Interview – http://bit.ly/Thk4eY)

4. Can organizations really benefit by using Kanban over the first generation Agile methods like Scrum & XP? Attend Masa K Maeda’s full day workshop on Kanban Primer http://bit.ly/RDCFmJ (Special Interview – http://bit.ly/SzHs5M)

5. How to over come some of the key challenges faced by teams when adopting Continuous Delivery? Attend Jez Humble’s full day workshop on Continuous Delivery http://bit.ly/RDCGab (Special Interview – http://bit.ly/SzHbzF)

6. What practical technical practices does an organization need to sustain and succeed with agile development? Attend Venkat Subramaniam’s two-day in-depth workshop on Honing Technical Practices To Realize Sustainable Agility http://bit.ly/RDCGHa (Special Interview – http://bit.ly/TDLU2t)

7. Why Agile Enterprises need to break down the silos in their organization? Attend Prof. David West’s full day workshop on The Agile Enterprise http://bit.ly/RDCJ5N (Special Interview – http://bit.ly/SzJItF)

8. Are there real advantages/benefits of using agile games as opposed to traditional methods like meetings? Attend Laurent Bossavit’s full day workshop on Playing Games for Fun and (Business) Profit http://bit.ly/RDCKqs (Special Interview – http://bit.ly/Upof8x)

Jez Humble (@JezHumble) is a Principal Consultant with ThoughtWorks, and co-author of Jolt Award winning book Continuous Delivery (http://continuousdelivery.com/). He got into IT in 2000, just in time for the dot-com bust. Since then he has worked as a developer, system administrator, trainer, consultant,  manager, and speaker. He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services, and online retail companies.

His focus is on helping organisations deliver valuable, high-quality software frequently and reliably through implementing effective engineering practices in the field of Agile delivery.

He will be running a one day workshop at Agile India 2013.  This week we spent some time with Jez and chatted to him about continuous delivery, a topic he is very passionate about.

1. How does continuous delivery improve collaboration between developers, testers, and operations?

Continuous delivery improves collaboration between everybody involved in software delivery by requiring it. It’s impossible to achieve high quality systems without developers and testers physically working together, and without developers being accountable for how the systems they build perform in real life. When testers work in silos physically separated from developers, quality always gets worse. When operations work in silos and don’t collaborate with developers, deployment is always going to be a high-risk, painful activity.

2. How do you sell the benefits of continuous delivery to clients who have infrequent releases?

The HP LaserJet firmware team just brought out a book that describes how they implemented continuous delivery: “A Practical Approach to Large-Scale Agile Development“. Obviously you don’t ship new firmware that often, but implementing continuous delivery provided enormous benefits for them. They measured team activity over the three years it took them to implement continuous delivery and found it reduced development costs by 40% and increased the amount of time the teams were spending on feature development (as opposed to non-value-add activities such as integration and manual testing) by a factor of 5. They implemented continuous integration and extensive test automation – they have 30,000 automated functional tests that run in virtual and emulated environments on logic boards – and if somebody checks in a change to version control that breaks the tests, the change gets automatically reverted straight back out of version control. The most important benefits of continuous delivery are second order – giving developers fast feedback so they can take responsibility for their actions, so they get rewarded for delivering work that is integrated, tested and production-ready, rather than “dev complete”. That forces teams to architect their systems with automated testing and deployment in mind, and to perform those activities frequently from early on. If you’re doing it right, you completely remove the integration and testing phase – your software is in a deployable state from day 1 of the build phase, which means releases are low risk, you can get feedback much more quickly and avoid working on features that aren’t valuable to your customers, and you can measure your progress and identify risks in a transparent way.

3. What are some of the challenges teams face when adopting continuous delivery?

The main challenges to adopting continuous delivery are organizational and architectural, and these two problems are tightly coupled (which is what Conway’s Law tells us). It’s usually best to start with continuous integration, which means every developer is checking in to trunk at least once a day, we build and test the complete, integrated system every time a change is made to version control, and if there is a problem everybody pays attention and we prioritize fixing it straight away. Doing everything in that one sentence is still a tall order for most organizations. Often there aren’t enough automated tests, the ones that exist are flaky, they’re expensive to create and maintain, and nobody cares much if they fail. Production-like integration environments are often expensive to provision and hard to get access to. Developers don’t work on trunk because it slows down the rate at which they can declare their crappy, buggy, undeployable code “dev complete”. It’s hard to retrofit automation to systems that aren’t designed for it, and it’s hard to retrofit CD into silo-based organizations. So adoption is usually impossible unless management is bought in and at least some of the engineers are willing to change the way they work. It’s always the organizational issues that kill you in the end.

4. What is the take away for the attendees of the workshop?

The low-down on how to implement continuous delivery in real life, even in large, distributed organizations. I cover everything from continuous integration to patterns for low-risk releases, with material on automated infrastructure management, managing databases, and how to create maintainable suites of automated acceptance tests. I also discuss organizational issues and the value proposition so practitioners are equipped to talk to their management. That’s a lot of ground to cover so there’s no hands-on coding, but the advantage is that it’s at a high enough level that anybody can benefit – developers, infrastructure people, dbas, managers, testers. One of the benefits is that just by getting all those different roles into one room, we can get an appreciation for the problems we each face, which usually leads to some interesting discussions.

Like all other workshops, this workshop has limited seats. Book soon to avoid disappointment: http://booking.agilefaqs.com

Past Talks: http://continuousdelivery.com/talks/

At Agile India 2013, we are offering 14 workshops, all under one roof from 16^th February to 2^nd March. This is a unique opportunity to learn from experts all over the world, don’t miss out! One of the workshops we will be running is titled ‘Kanban Primer’, by Masa K. Maeda.

Masa is the creator of Lean Value Innovation, he is an internationally recognized expert on Lean and Agile Project Management, Kanban and Scrum. He started Valueinnova in the Silicon Valley California in 2008.

He has spoken at several conferences including Lean Kanban and Agile India 2012. He was one of the favorite speakers at Agile India 2012 based on the feedback we received.

We stole some of Masa’s precious time and quizzed him about Kanban and its benefits.

1. What are key benefits of Kanban over the first generation agile methodologies like Scrum?

Kanban is a fabulous practice that is equally applicable to technical teams and to management and leadership teams. The biggest benefit of Kanban is that it brings an amazingly effective way to improve process and to generate a culture of continuous improvement with very minimal effort. It is also fun to do. It accomplishes this by being highly adaptive and improving value flow over existing processes. This is great news because it means Kanban is equally applicable to organizations doing Waterfall, Scrum, XP, or other. Yes, this means it also helps improve value generation and delivery over other agile methodologies. It also means it can be applied beyond IT and software development. Some people think Kanban is only good for IT work but that isn’t actually so. We have applied it very successfully to Software Development, Admin, HHRR, Healthcare, Education, Telecommunications, etc.

2. Is it possible to introduce Kanban into an an organization this is already practicing Scrum/XP?

Definitely yes. Kanban is compatible with other methodologies. It actually helps improve the performance of Scrum and XP teams. Kanban has been proven to actually make it easer for agile adoption to spread more easily and more quickly. One example of how it helps improve Scrum is by improving the flow of Stories and also by bringing an effective way to handle urgent tasks. For XP teams it allows to better visualize the work to do and being done, aligning better the dev-test activities as well as the UAT. In both cases it increases customer satisfaction because value delivery improves over time.

3. Who is the workshop intended for?

It is equally good for executives, managers, and team members. Executives benefit using Kanban, for example, to manage their business and customer portfolios, and by reducing time-to-market. Managers benefit because Kanban gives them visibility and predictability over projects; and by reducing delivery time through continuous improvement. Team members benefit because it increases autonomy, effectiveness, and quality. It is important to understand that Kanban is not a technical practice but rather a discipline to improve what we currently do, be it technical or managerial.

4. What is the key take away for the attendees?

 This workshop will allow them to get enough knowledge to get started with Kanban. They will have the bases of its system and the method itself. This means they will be able to figure out how to create an effective Kanban board, generate the key elements to have high visualization, to do root-cause analysis and to effectively increase value flow. The workshop is highly interactive through lots of team exercises. It will be a fun day. Our training typically gets the highest scores during evaluations because of its format and because of the amount of knowledge and understanding acquired by the attendees.

Past talks:

Lean Value Innovation – Agile India 2012

Seats are limited for this workshop, book soon to avoid disappointment: http://booking.agilefaqs.com

Kevlin Henney is an author, presenter, and consultant on software development. He has written on the subject of computer programming and development practice for many magazines and sites, including Better Software, The Register, C/C++ Users Journal, JavaSpektrum, C++ Report, Java Report, EXE, and Overload. He is a member of the IEEE Software Advisory Board. Henney is also coauthor of books on patterns and editor of ’97 Things Every Programmer Should Know’.

Henney has given keynote addresses at a number of conferences, including ACCU, DevWeek, Embedded Systems Club, GeeCON, GOTO, JAOO, Jfokus, NLUUG, OOP, PHPNW, SDC, Software Architect, and XP Day.

We are really excited to have Kevlin present his workshop on ‘Architecture with Agility’ at Agile India 2013.

This week we interviewed Kevlin and got some more information about his workshop.

1. Agile practices talk about emergent design and iterative production, how does architecture fit into this model? Is agile architecture emergent?

Process influences and is influenced by what you build and what you can build is influenced by process. Software architecture can best be considered the set of significant design decisions, where significance relates to cost and difficulty of change. Agile projects that do not consider their architecture are not likely to remain agile for long. If an agile project focuses on delivering functionality at the expense of a design that supports incremental development, it will find itself struggling to deliver functionality.

Of course, what constitutes a significant design decision is not obvious up front, so establishing an architecture is necessarily a dynamic that flows through the whole development rather than a fixed activity locked into an early phase of development. Architecture embodies knowledge, knowledge is acquired by learning and learning takes time; a development process structures this time.

2. What are some of the misconceptions about agile architecture?

The most obvious misconception is that a good architecture will just happen and emerge miraculously from a succession of iterations, without focused responsibility and effort. Agile architecture requires guidance and nurturing, shaping a system through a succession of changes, each considered to be an experiment against a hypothesis, each considered to be open to review and change.

3. What is the key take away for the attendees from the workshop?

An architecture will constrain or enable the process of development. If you want to be agile, want to make changes frequently and sustainably, want to deliver and get feedback more often, then you need an architecture that supports rather than frustrates such a process. And, like most things in life, if you want good architecture, you have to care about it.

Past talks by Kevlin:

• Cool Code, GeeCON 2012
• Putting the “re” into Architecture, QCon London 2011
• Patterns for the People, Øredev 2010

Kevlin’s workshop has limited seats so go ahead and book at http://booking.agilefaqs.com before it is too late!