In order to successful scale any method or practice, it has to have some basis in theory. This presentation will use insights from complex adaptive systems theory and the cognitive sciences to lay a foundation for that theory. Seeing software development as a problem of knowledge management, the theory will elaborate a understanding of applications as the emergent property of a co-evolutionary interactions between technology capability and unarticulated user requirements.

Having established a basic theory a range of methods and tools will be elaborated. These include:

- Narrative based approaches to requirements capture (not to be confused with Story telling or story boarding) which gather thousands of fragmented self-signified anecdotes relating to real and imagined needs within a user community and allow interpretation and integration into project planning.

- Approaches to project planning and implementation that focus on the creation of self-organising teams of specialists and users to create novel approaches, supported by evidence to previously intractable problems. This is particularly relevant to the 5-10% of any major project which creates 95-90% of the grief.

- The integration of tools such as blogs, wiki's etc into the development environment. Too often corporate environments over-constrain those tools into over rigid structures which destroy their utility.

How organizations are learning to value learning and not just velocity!

We all hate wasting time and money.  In the pursuit of cutting out waste, we've learned to systemically fool ourselves – to convince ourselves with very little evidence that the activities we're engaged in add value.  And, further, activities that don't result in a product we can deliver are waste.  But, the biggest leap of faith I continue to see most companies make is in believing that people want their new product, feature, or idea.  They likely don't.

This talk is about the rise of learning as a valuable activity.  I'll give examples of organizations that invest in experiments that take the cooperation of developers, testers, product mangers, infrastructure, sales, and marketing.  At the end of these experiments organizations are left with no deliverable product and only the knowledge that the product they're thinking of should or shouldn't be built at all. 

On Reddit, IAmA stands for "I am a" and AMA stands for "ask me anything".

In an IAmA post, a person will post what they are, and other people will ask the original poster some questions to gain insights about the experience the person has had.
 
Ex: I'm Jeff Patton, creator of Story Mapping, Ask Me Anything... OR I'm Diana Larsen, co-creator of the Fluency Model and co-author of Agile Retrospectives, Ask Me Anything...

We plan to take this concept and apply it to the Agile context. We've few luminaries at the conference and we plan to do an live interview with them using this format.

As lead developer of Cucumber and author of The Cucumber Book, Aslak gets asked to consult with organisations who want to introduce Behaviour-Driven Development (BDD). Time after time, he meets teams who are trapped doing half-arsed agile. They do the easy, obvious, visible agile practices, and none of the powerful, hard-to-master, hard-to-see ones.

When these teams ask for help learning BDD, we get a chance to remind them how important conversations and collaboration are in software development. We teach them to write tests before they write code, as a way to explore and discover the hidden details of a requirement just before they dive in and start building it. This talk will make you wince with recognition, laugh with despair, and finally inspire you with stories of teams that have finally, after years of flaccid scrumming, discovered the true collaborative heart of agile software development. You’ll see patterns you recognise from your own teams, and gain insights about how to fix them.

Education is a critical component in a sustainable agile transformation. Sustainable agile is realized when people have truly change the way they think – that needs education. If we truly understand that we need to change the mindset of everyone in the organization, including its leaders, then we need a combination of education, coaching and mentoring to successfully equip people with the knowledge and skills they need to develop and execute agile habits. If we think of agile as a process, not a mindset, then we default to training instead of education.

While we acknowledge our bias towards the learning roadmap published by the International Consortium of Agile (ICAgile.com), we truly believe that it is the most comprehensive roadmap in the agile community that focuses on a common education roadmap for agile and agility and not training on a particular agile methodology. ICAgile has gathered experts from around the world and they have collaborated to define an education roadmap for every discipline needed to change how the organization as a whole works, and provides education as a foundation for sustainable organizational agility. (Focus on people not process, education not training)

Certifications are a way to give people confidence in the learning and competency of others. Agile certifications should be no different. ICAgile has developed a set of competency based certifications to ensure we keep the focus on Education. 

Dance with Diana Larsen along the path to Agile Fluency for your team. In 2012, Diana Larsen and James Shore refiined the Agile Fluency Modeland Martin Fowler published it, "Your Path Through Agile Fluency." (http://agilefluency.com) The model describes how teams grow in their understanding and skillful ease with Agile over time. The model reflects what Diana and Jim, and many others, have seen in real teams in the real world, and it inspires organizations to learn how to invest in teams. In this keynote, Diana will share stories of real teams as they dance along the path and energize you to find your teams' best dance.

Scaling Agile is the hot trend these days. There are various options people are currently using to scale agile across their organization ranging from the trendy SAFe through the evolutionary Kanban all the way to classic LeSS. As an enterprise agile coach with straddling both the Kanban and SAFe worlds with experience helping various global enterprises to be more agile at scale I have a wide perspective of the agile scaling approaches landscape which I will share in this session. Together we will look at the various leading approaches to Scaling and understand how they compare, where each is appropriate, how to mix and match them. We will also spend some time discussing change management/implementation aspects of using the  the various approaches and how to move through the selection, kickoff, stabilization and recharge phases and ideally move to improve mode at some point. 

Agile has proven very successful at the team level, but most organizations find it very challenging to scale agile tools and principles to the enterprise level.

in this keynote will discuss the Agile manifesto's values and principles and ask ourselves if and how they scale.

I would like to tell the story of some of my experiences in scaling agile in multiple companies, both good and bad, and what I've learned about appying Agile at Scale.

I will finish by discussing why SAFe can be a good option for scaling Agile, examine it in the light of the Agile Manifesto and talk a bit about how it approachs scaling Agile priciples and tools.

Organizations are applying agile strategies with large teams, geographically distributed teams, in outsourcing situations, in complex domains, in technically complex situations, and in regulatory situations.  Sometimes they’re successful and sometimes they’re not.  The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable. The DAD framework is a hybrid which adopts proven strategies from Scrum, XP, Agile Modeling, Outside-In Development, Lean/Kanban, DevOps, and others in a disciplined manner.  In this presentation you’ll discover how DAD provides a solid foundation from which to scale agile, learn how agile teams work at scale, and identify several common scaling anti-patterns which should be avoided.

Is business process improvement part of Lean IT? What about best practices and benchmarking? Is agile software development a Lean IT practice? What about IT operational excellence and the ITIL service management framework? How about performance management dashboards and scorecards? Is applying Lean techniques to project management considered a Lean IT practice? And is cloud computing relevant in a Lean IT world? The answer to all these questions is yes. But Lean IT is much more than just a set of tools and practices; it is a deep behavioral and cultural transformation that encourages everyone in the organization to think differently about the role of quality information in the creation and delivery of value to the customer.

Lean IT enables the IT organization to reach beyond alignment toward fundamental integration, cultivating an inseparable, collaborative partnership with the business. Whether you are new to Lean, or a seasoned veteran, in this book you will find new insights into the power of Lean and the critical impact of an integrated IT function. In this discussion Patrick Phillips will explore all aspects of Lean IT within two primary dimensions:

Outward-facing Lean IT: Engaging information, information systems, and the IT organization in partnership with the business to continuously improve and innovate business processes and management systems

Inward-facing Lean IT: Helping the IT organization achieve operational excellence, applying the principles and tools of continuous improvement to IT operations, services, software development, and projects These two dimensions are not separate but complementary.

The adoption of the term Lean software development is more than a name change. While agile is a set of development and life cycle management tools and methods focused on the just-in-time development of quality software, Lean software development addresses a larger context: the environment within which the software operates, the value streams of the enterprise. For example, in a business application, properly functioning software is viewed as a supporting element of the business process. In an embedded software application (such as the operating system of a smartphone or the control systems of a jet aircraft), the software is part of the overall product design and value proposition to the customer. Lean emphasizes seeing the whole through the eyes of the customer, not its component parts through the eyes of the designer or developer. “Lean software development views all Agile methods as valid, proven applications of Lean thinking to software,” says Jeff Sutherland, a signer of the Agile Manifesto. “It goes beyond Agile, providing a broader perspective that enables Agile methods to thrive.”

In the words of Mary and Tom Poppendieck, “A Lean organization optimizes the whole value stream, from the time it receives an order to address a customer need until software is deployed and the need is addressed. If an organization focuses on optimizing something less than the entire value stream, we can just about guarantee that the overall value stream will suffer.” We have witnessed many skilled agile practitioners fall into the common Lean trap: focusing on tools and techniques rather than solving problems and eliminating waste. Lean software development expands agile’s focus from optimizing the software development process toward improving entire value streams. Thus, Lean software development must integrate and synchronize with all business processes, management systems, and kaizen activity, supporting the Lean transformation of the overall enterprise.  This session will take you into a discussion with a practitioner who is one of the industry's leading figures in understanding and utilizing lean. 

As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user's needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

Most software organizations today suffer from what I call, the "Inverted Testing Pyramid" problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.

An intro to design thinking ideas...

Make better decisions

Learn to engage with the unanticipated for strategic advantage. For leaders, consultants and project managers.

How to manage uncertainty in increasingly complex environments?

The ability to manage and navigate complexity is a key strategic advantage. However, many organizations are trapped in past practices and structures. Breaking through such inertia requires praxis - theory informed practice.

The Cynefin framework, and its application in managing complexity is at the heart of this training program.

The Academy of Management awarded the Harvard Business Review article, Cynefin & Leadership, the "Best Practitioner Paper". Their citation reads:

"This paper introduces an important new perspective that has enormous future value, and does so in a clear way that shows it can be used. The article makes several significant contributions. First, and most importantly, it introduces complexity science to guide managers’ thoughts and actions. Second, it applies this perspective to advance a typology of contexts to help leaders to sort out the wide variety of situations in which they must lead decisions. Third, it advises leaders concerning what actions they should take in response"

Cognitive Edge has developed a modular training program that allows participants to understand the theory of complexity and how to put it to practice.

Crucial new knowledge for:

• Project management
• Change management
• Innovation and development
• Risk and crisis management
• Shaping culture
• Safety management
• Knowledge management

We would like to share our experience and journey on how we brought down our Jenkins build pipeline time down from over 90 minutes to under 12 minutes. In the process, we would share specific techniques which helped and also some, which logically made sense, but actually did not help. If your team is trying to optimize their build times, then this session might give you some ideas on how to approach the problem.

Development Impact - For one of our build job, below graph shows how the number of builds in a day have increased over a period of time as the build time has reduced. Frequency of code check-in has increased; Wait time has reduced; failed test case faster to isolate and fix.

Business Impact - More builds leading to quicker feedback and faster story acceptance and less story spill over.

While having a chat with Naresh Jain, he suggested me to go through the Ted Talk – “Gaming can make a better world” by Jane McGonigal. I found the title very weird and was wondering how is that possible? After going through the talk though, I was amazed. I started wondering if I can use the gamification technique in Agile Adoption, in our Products, in Performance Management Systems, in Employee Engagement Programs?

Dhaval Dalal introduced me to Prof. Kevin Werbach’s definition of Gamification – “The use of game elements and game design techniques in non-game contexts.”

For our 4th ShipIt Day, organized on 25th/26th Sept 2014 at IDeaS, I decided to explore the idea of using game elements and game design techniques in the context of Agile Adoption. The idea was to create a gaming system which will automatically collect data, i.e. without explicit user intervention, from multiple sources like Jenkins, Rally and manually from individuals and offer Star’s for positive behavior and deduct Star’s otherwise.

The aim was to help the team get continuous visual feedback on how they are doing, adopt agile practices, visualize sense of accountability, visualize sense of achievement, drive positive behavior, create healthy competition, create a culture of appreciation, help performance tracking and create transparency.

Update -

1. Deducting points seems to be bothering the individuals. Now we are experimenting with getting rid of negative points and introducing short lived badeges instead e.g. "Build Breaker".
2. We have now added more badges to recognize individual efforts in various categories.
3. Working on open sourcing the core app at https://github.com/IDeaSCo/rockstar

Good engineering practices and fail-fast, iterative, low-ceremony processes help achieve team level agility. They are necessary but not sufficient to scale agility across the IT organization. In this talk, I'll address what else is needed and why. In particular, I'll address:

1. Why plan-driven IT projects are a bad idea why we need value-driven projects instead
2. Why a matrix org is a bad idea for IT and why we need cross-functional teams instead
3. Why IT budgeting needs to change from being project-based to being team-capacity based

2 major errors across 6 agile planning events give us 12. Learning “what not to do”, can sometimes help us identify risks early in the cycle so that, as a team, we can effectively respond to these risks.

Agile planning happens at multiple levels. In scaled agile delivery model, effective outcome of one planning event can influence the other significantly either positively or negatively.

Come and learn top 12 experiential insights. These will help you alert your teams on “what not to do” during Scaled Agile Planning events. I tried capturing top 12 errors across 6 planning events namely Strategy Planning, Portfolio Planning, Product Planning, Release Planning, Iteration Planning and Daily Planning.

In order to achieve my goals, as a buyer of your product, I want awesome feature.

AT: make sure your users stories don't get in the way.

Users Stories, the tool teams use to break big ideas into small demonstrable deliverable, are easy to describe and challenging to write effectively. In this hands-on workshop you'll learn how to write great user stories that adhere to the INVEST principle. We'll learn various techniques to slice your stories using the vertical-slicing approach. We will discuss what elements should be included in the stories, what criteria you should keep in mind while slicing stories; why the size of your user story is important and how to make them smaller and efficient.

This presentation brings a different perspective for the Scrum Masters and helps them to become more powerful Scrum Masters through their enhanced soft skills. I am going to cover how the teams evaolve, how the change is resisted, how the teams behave, how Scrum Master can handle all these effective to make the teams deliver working software every sprint continuously.

The information explained below is from my experience as Scrum Master and Coach. Below are the points that will be covered in the presentation:

Primarily I am planning to cover the anti patterns that will push the teams back and where the Scrum Master can support the teams with his knowledge, experience and interpersonal skills. For example please find below some scenarios:

1. In effective sprint planning: Team might miss some of the tasks while doing the sprint planning part 2 so they will anyway identify them during the development of the stories so these tasks take additional time which is not budgeted. So they will have to miss some stories which will impact the sprint goal. So I encourage the scrum masters to collect all such unidentified tasks on a separate colr sticky notes and during retrospective discuss with the team to see how much % of the capacity is gone for that tasks. At the same time are there any tasks in that list can be repeatable tasks (Eg: Code review) so this will help the team to come up with a tasks checklist which will help the teams to do effective sprint planning part 2 

2. Partially ready stories pushed into the sprint: Sometimes product owners push the stories that are not fully ready and the team cannot say "No" in this case either the story gets changes during the sprint or it cannot be finished due to unknown factors. So Scrum Master to encourage the team to have a proper DOR (Definition of Ready) and get a working agreement between the PO and team so that they will work around it whilst they understand "Responding to change over following a plan"

3. Cross functional behavior: Team generally does not want to become cross functional because they are fine with what they are. Scrum Master has to bring a change in their thought process and get them agreed to become cross functional. For this it takes time so SM has to also manage the management expectations with respect to set the expectation in the dip in productivity

4. Pale retrospectives: This is another area where Scrum Master has to provide support to teams and get the liveliness and make the teams high performance teams

5. Timeboxing: Most of the teams do not respect this important guideline. Again SM has to get the importance of this characterstic in to the teams and get them aligned towards this. So there are some examples which I can quote such as if different people arrive at different timings, how much time is wasted and how many times we need to recap on the points already discussed, how much gap created etc

6. Stop starting and start finishing: This will cover to complete the stories/tasks that you are working before you pick up something. In general the teams pick up many items at a time and complete them close to 100% but not 100% so this will impact the sprint goal. In such case the SM has to provide inputs to the team to pick as few as possible but close them as soon as possible so this way the value delivery at the end of sprint is guaranteed

7. Lack of importance for quality: In the hurry of completing the stories the team at times give less or no importance to the quality. So the probability of escaped defects or getting rejection for the stories is high. So the Scrum Master has to educate the teams to strictly define/refine/follow the Definition of Done for each story. I saw many teams having their DOD in the tools like VersionOne but not infront of their eyes. 

8. I know when I see it: Information radiators. This will be the key for the teams to adjust their pace as per the principle #8. So creating big visible information radiators and updating the underlysing details frequently will bring attention in the team and they naturally tend to adjust their delivery mode as per the requirement