A reflective design approach to achieve software design agility by modelling change as a vector and tracking it to aid refactoring decisions.

Preface about the talk

Software design is a field that has always fascinated me and I have tried to be an obedient student trying to learn this art. Like any other design problem, software design is also a wicked problem. Horst Rittel and Melvin Webber defined a “wicked” problem as one that could be clearly defined only by solving it, or by solving part of it .This paradox implies, essentially, that you have to “solve” the problem once in order to clearly define it and then solve it again to create a solution that works.

Hence you need an architect with magical powers to get your design correct in the first go .This is the core philosophy behind emergent design in which we do not think too much about future . As Uncle Bob sarcastically points out, your customers somehow knows your design and they will come up with a requirement that will break your assumptions and thus your design. In emergent design you embrace aggressive refactoring religiously and few teams rebelliously for the good. It has also been observed that during emergent design refactoring step more focus is towards class design than higher abstract architecture elements. This creates technical debt which can go unnoticed for a long time.

In this talk I will be introducing a novel technique called change vector tracking that will address the above described problem. Change Vector Tracking is a reflective design approach to achieve software design agility by modelling change as a vector and tracking it through ceremonies like Change Vector Tracking meetings.

Change vector tracking doesn’t prevent customers from coming up with requirements that would invalidate previous design assumptions, it helps us in monitoring these changes and aids in making informed decisions of where and when to redesign. It helps us keep a check on design debt which otherwise would be overseen and not addressed at the right time .Design debt is invisible to tools initially, only when it grows beyond a scale tools can catch it. Change vector tracking is a technique to capture this design debt in a very early stage. “A stitch in time saves nine”.

According to the 11^th annual State of Agile report by VersionOne, one of the top five reasons for adopting Agile is to “enhance software quality”. In spite of this aspiration, a common pattern in Agile roll outs is the failure to set quality goal improvements from the outset. It is often assumed that if you implement Agile/Scrum then quality will just take care of itself. As many organizations quickly discover, you cannot just “deploy Agile” and expect it to be the silver bullet for a software organizations’ quality issues. Why is this happening so frequently? Is it due to methodical deficiencies, unrealistic expectations, fundamental misunderstanding of Agile, lack of executive support, too much existing technical debt or all of the above?

If you are questioning whether your Agile roll out is really helping you deliver higher quality software, faster, then this talk is a must to attend. I will discuss the approach I have successfully used in a number of organizations which involves; identifying the necessary building blocks to establish a quality mindset in an organization, moving the organization to a test first mindset, helping the Product Management organization become more Agile, and finally setting the right level of test automation so that you can deliver quality software faster.

If you are serious about doing Agility at scale, you cannot realistically achieve that goal without ensuring that each team individually delivers quality, and in-turn whole projects/programs that incorporate outputs from the individual teams are delivering quality software. To successfully scale quality, you will need to follow the ‘blueprint’ provided in this presentation.

When you learn about agile practices, one of the most challenging concepts to grasp is Story Point Estimation. This is particularly true for service companies that normally bill clients by the hour.

On the one hand, they need to submit project proposals that are based on concrete time estimates.

Story points, on the other hand, are an abstract concept by design. They were born out of the needs of product companies with the purpose of having a better assessment of the amount of work involved in developing software units, regardless of how long each unit takes. This makes people struggle between using points and hours. You want to reap the benefits of point estimates, but you still want to keep things tied to time.

In this session, I will introduce the notion of point estimates, highlighting its advantages over hour estimation. Then I will explain one approach to doing point estimation in a professional services company. I will address common concern from various stakeholders from Project Management to Business Development, COOs and CEOs.

Lean UX research is essential to guide and validate what exactly is the 'Minimum Viable' to launch a Minimum Viable Product, especially in government.

In this talk, I'll describe how user research insights helped us understand, design and launch Canada's first online open-source regulatory consultation. The first research participant identified a significant hole in our assumptions - and predicted that we could miss the minimum viable mark. It helped us course-correct, and plan ahead for the next development iteration.

The other customer group was the government. We applied lean UX research techniques to understand the government analyst team's journey and needs, and then to co-design with them as the analysis site MVP was developed, and as the commenter data flowed in.

I'll describe how the insights from the research helped us meet the Minimum Viable mark for the government customers, understand how and why we missed the mark with the specialist customers and how you can apply lean UX research techniques to ensure you don't iterate your way to a useless product.

In the federal public service there is an air gap between the performance evaluation criteria applied to business leaders and the criteria applied to service providers.

As a consequence, even in situations where both the business and the service provider enjoy optimal relationships, the goals are not the same and may even be contradictory.

In a climate centered on Results and Delivery, leaders cannot expect results if they do not tackle this conflict.

The approaches proposed in this discussion align the service organization to the business. They promote mutual accountability by insisting on mutual performance alignment between the business and its services provider.

When Agile first came on the scene it was premised around putting the customer first. But, over the years its focus has evolved and the general perception of Agile today is that it’s mostly a tool for delivering software. Agile’s original focus was mainly on developers and testers, but it never really contemplated design thinking as a discipline. Design thinking, which has been around for decades but is only recently having its ‘moment in the sun’, compliments agile beautifully in that it focuses on trying to solve the right problems for the right people. Design thinking allows us to iterate and test assumptions before too much coding and production-readiness is done, which helps ensure the team is investing in the right things at every stage. It really provides a focus on innovating rather than simply burning down a backlog. In this talk we will discuss different ways to incorporate design thinking into the agile process. You will learn how to yield benefits from bringing these two practices together – most importantly how to best serve the users of the product or service you are delivering. At Scotiabank, we’ve been using these fantastic tools in combination for over a year. It is a journey, and although we haven’t completely solved everything yet, there are a lot of lessons we have learned that can be applied elsewhere.

Confused about Continuous Integration vs Delivery vs Deployment? Not sure how to take the next step towards Continuous Deployment?

In this session, Nayan will remove the confusion around the "Continuous" terms. He'll then show you how to go from Commit to Production with no manual steps, while remaining confident that your production system remains stable. We will do this with a variety of open source tools -- from traditional build & integration tools to modern deployment environments & monitoring. You'll leave the session inspired and ready to build your own Continuous Deployment Pipeline when you get back to work.

Agile helps you deliver value to customers faster. Good user stories allow you to capture, prioritize, communicate, and deliver on that value. In my experience, a major impediment to writing good user stories in the real world is a lack of example stories. Here is a set of games that incorporate 80 examples of good and bad user stories. The games are easy to learn, play, and teach and take just a few minutes. Come play and enjoy sharing them with your friends and co-workers!

This session I will review how we used a physical Kaban board and post-it notes with Jira and the Agile Cards plugin to sort through a sea over 500 of Jira issues in various states of progress. The process was complicated by a large number of projects with inconsistent workflows and confusing states ("In Review" could mean in code review or in QA review). I will review how the team members worked to examine and group issues, place them into the right state, abandoning some, moving others to the back log and prioritizing the rest. I will also show how having a physical board change the nature of our stand-ups and how we updated Jira to match the board.

(at the current time this is still a work in progress, but I will add to the presentation as we work towards a mature system. Update: I am no longer with the company I started this at and I did not get to complete migrating to a mature system, but I did learn some valuable lessons on the way.).

Although self-organizing teams are crucial to carrying out a successful Agile transformation, organizations that implement Agile at scale invariably realize that the introduction of such teams forces the organization to re-engineer numerous aspects of its operating philosophy. In particular, various management layers are often removed. The individuals in these layers are routinely re-purposed or laid off.

This talk highlights the approaches I used as an Agilist in various organizations to help people in different roles on their journey of transitioning into the world of Agile. Specifically, the talk will focus on 5 key roles: Project Managers, Product Managers, BA Managers, Development Managers, and QA Managers. It will provide insight into how managers can effectively transition to some of the new Agile roles, or redefine their existing role to effectively fit in an Agile world.

The emphasis in this talk is on pragmatic strategies for managers that are struggling to find their place in this new Agile world. Armed with these strategies, participants will be able to effectively adapt to the Agile transformation, as well as discover potential new career paths for themselves and for the individuals reporting to them.

This workshop can be given in either French or English ....

Enterprise agility come in numerous flavors. Participants will be confronted with the false choices presented to them (Flow vs Iteration, feature teams or competence based) by different approaches and be better able to build bridges between islands of agility (Scrum, LeSS, SAFe, Kanban)

The OKALOA FLOW LAB is a new simulation created by Patrick Steyaert, conceptor of Upstream Kanban, Discovery Kanban, Portfolio Kanban, Customer Kanban. He is a world leader in all matters related to agility.

The simulation is fantastic.

Why do some Agile teams become shining innovators and others struggle? This workshop will guide teams to understand the natural elements and flow of team problem solving. They will learn techniques to tailor the process for each team’s members. By doing so, they will unlock the natural innovative nature of every team member and find the “wisdom of the crowd” — how the people on an Agile team can wring out every last ounce of their creative best in service to their projects and each other.

Sorry to say it guys, but Agile has gone limp over the last few years.  As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce.  Not great stand-ups.

Technical practices matter.  In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that.  From a Lean perspective, process adds no customer facing value.  But getting rid of all process is crazy talk.  Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process.  In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company.  He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.

But perhaps we don’t have the absolute best talent out there.  Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?)  Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”?  With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?

I’d like to convince you that what’s going to work for your organization and your employees is something in the middle.  I, of course, lean into the “better technical practices will yield better outcomes” frame of mind.  You may as well.  But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that's the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire!  And the same is true of your organization.  It can logically be true that all organizations’ developers are all above average.  But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code. 

This session will speak to the specifics of the whats and whys.

As agility spreads across organisations, the agile practices regarding execution have grown more mature and reliable. The inception phase of projects, however, remains challenging to many agile practitionners. For a long time, we pursued balance between a reckless all-in approach or a long and tedious path through stage gates and chains of approval. As a solution to these concerns, we came up with a path we refer to as the Fast Inception. This path, built with a dense and intense agenda collaborative workshops, is bound to provide a both shorter and safer way to bootsrap your project.

In today’s fast paced world, we in the Agile community have gotten better at organizing and prioritizing work. We have learned how to focus on high value and eliminate waste in our processes. And yet so much of Agile these days is focused on how we move work from an idea to production while ignoring or undervaluing how to build high quality working software. Our focus is on how to hold retrospectives, collaborate with product owners, and hold daily standups but very little attention has been paid to how we write and test code. This puts your business at risk.

Join Cheezy as he talks about how we often miss the target in our “Agile Implementations”. Instead, he will challenge us to focus on technical excellence as the true Path to Agility. His lightweight approach for teams to deliver software with Zero Defects strips most methodologies down to their bare essence. This allows teams to focus on what is really important - rapidly delivering working software to customers. If you’re ready to take the next step in your agile journey then you won’t want to miss this talk.

Agile is not about doing scrum, kanban, lean or any other flavour of the process. An organization cannot be “doing” agile, they must “be” agile. They must believe in and understand the agile principles. After going through a successful agile transformation and running scrum for 3 years we realized that it’s just not working for us anymore. The team was suffering from scrum fatigue. It felt like there was a sprint planning, stand up or retrospective meeting happening all the time. We decided to take a hard look at how we were working and turn it on its head. We looked at all the different agile options such as scrum, kanban, lean, xp, etc and decided to take the best part from all of these instead of sticking with one approach. This session will take you through our journey and share what worked for us that could also work in your organization

As a Product Owner, I am sure this has happened to you. You worked with a team on an initiative and it resulted in something different than your vision. The customer was not happy, you were not happy and the team felt they had done everything that was asked.

How do we change this? How do we build a common understanding around the product vision?

User Story Mapping is one of the tools that can help bridge the gap from idea to fruition. Story Mapping can be applied to software development and real life situations. It requires only a few simple ingredients: user personas, customer journey and clear outcomes. This will provide a basis to discuss, prioritize and slice your backlog. Story Maps are a great way to guide a team to quickly creating a minimal viable product and validate the solution fit.

When I was a product owner, I have created story maps on initiative, portfolio, feature levels of my product. They have helped articulate my vision with the team, and the team refined the product vision.

In this session, we will create a Story Map, leverage tools and techniques like empathy map, Kano model and MoSCoW to slice backlogs and most importantly tell your story. This workshop will hopefully help Product Owners and teams to focus on the user's journey.

Large companies (Banks, Insurance, and Telecom) in our community have been on their Agile Transformation journey over the past 4 to 5 years, implementing Agile in various pockets of the organization. Leaders have made significant investments of time and money on this journey and are now facing the challenge of articulating tangible benefits of the transformation and would like to measure the efficacy of the transformation.

Basically, they are asking Is Agile Working?

While there is no one simple answer to this seemingly innocuous question, we have from our experience working with these different clients devised a process that has helped us with answering this question.

In this session, we would like to share the three step process which we hope will help you.

• Firstly, we start with identifying the personas in the organization who are asking the question. And in our experience, we have identified (at least) four major personas that work for this scenario.
• Secondly, we identify the business objectives and outcomes that these personas want to achieve. This involves multiple workshops and sessions with these personas to identify their objectives and outcomes.
• Finally, we introduce a 3 * 3 matrix based on the organization lens (personas) and the maturity of Agile capabilities in the organization

The three step process identified above has proven to work irrespective of the industry it is being used in and provides a comprehensive and structured way to answer the important questions that an organization faces during the transformation. This process and the accompanying tool provided enable executives to make data backed decisions on the areas to focus on next in the transformation.

This is a new presentation with the goal of sharing our lessons learned in the adoption of an agile project management approach, with a focus on Scrum, within our web development (Drupal) agency.

The rules and practices for Scrum - a simple process for managing complex projects - are few, straightforward, and easy to learn. But Scrum’s simplicity itself - its lack of prescription - can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results.