Agile-Lean International 2020 conference

Technical Debt is perhaps the most difficult concept to get across to business and non-technical stakeholders in an organisation. It has traditionally been the IT “thing” conversations of which are better banished to the basement. As a business, you can go fast and take some debt, but it is often forgotten that this debt needs to be paid back. Technical Debt has always been a black box for the business leading to a lack of sponsorship and funding. A symptom of this is that any work to pay down debt needs to masquerade as feature work or as part of defect fixes. This is not sustainable though as the debt load grows there is only so much debt you can pay down under the guise of features, defects and non-functional requirements and all it does is mask the problem.

To change the way business views and perceives technical debt, a radical change is needed in the way it is viewed and treated at all levels in the organisation - not just IT. It’s time to have an open conversation about Debt with the business and give it a seat at the table when it comes to planning software delivery and correlating it to business value. It is not easy, this change needs perseverance and time, but it can be done. 

In this session, Laksh Ranganathan - Snr. Flow Advisor at Tasktop, talks about how Tasktop is helping organisations to make Debt visible and bringing it to the forefront of product planning.

The way agile software teams gain knowledge about what to build is either by the product owner or business analyst serving as a proxy to domain knowledge. Domain knowledge usually ends up as second-hand news in either functional design documents or as user stories in some scrum tools like Jira. Second-hand knowledge is a problem because ‘It is not the domain expert’s knowledge that goes into production; it is the developer’s assumption of that knowledge that goes into production’. Because by sharing knowledge by doing the ‘telephone game’, where each time knowledge is transferred, assumptions create lies within those requirements.

Sharing knowledge is way more effective if we actively collaborate to gain new insights about the problem at hand. There are a lot of tools available to achieve it, but they have a steep learning curve, resulting in most disciplines having their own tool to model in. To solve it, we need visual collaborative modelling to learn between multiple disciplines. EventStorming is a technique that can facilitate visual collaborative modelling between the different disciplines. It is easily learned and empowers continuous knowledge sharing without the need to know a tool.

In this session, you will experience how easy it is to learn EventStorming and at the same time gain a lot of new insights about a new domain. We will facilitate a Big Picture EventStorming session where we will create groups of 20-30+ people sharing knowledge at the same time about a domain. EventStorming gives you the power to create a shared mindset and merge on your models without needing tools. You will experience how EventStorming can reduce requirements engineering from days to hours, increasing feedback, and ending up delivering the expected features.
The way agile software teams gain knowledge about what to build is either by the product owner or business analyst serving as a proxy to domain knowledge. Domain knowledge usually ends up as second-hand news in either functional design documents or as user stories in some scrum tools like Jira. Second-hand knowledge is a significant risk when building software. Each time information is transferred just like doing the telephone game, the story is changed, and people make assumptions. Because as Alberto Brandolini said: ‘It is not the domain expert’s knowledge that goes into production; it is the developer’s assumption of that knowledge that goes into production’.

Even when these stories are shared first hand, they usually are discussed sitting around a table looking at a screen showing the user stories. Addressing complex problems without visualisation is impossible for most humans to solve. Doing so resolve in making a lot of assumptions again, which will stop us from building the right thing.

Join us in this session where I will explain how visual collaborative modelling can help you write better software. Through proper preparation and facilitation, we can co-create solutions. Co-creating solutions by visual collaborative modelling make sure we have buy-in from the entire team. You will end up knowing how to start your visual collaborative modelling journey with tools like EventStorming and Example Mapping.

"How can you possibly be productive with 5 people working at one computer?"

This is frequently the first question someone will ask when they first hear about Mob Programming. With Mob Programming 4 or 5 or more people work together at one computer to create software. It seems preposterous, but it's worked well for us, and for many teams. But how can this possibly work?!

Well… I don't propose that I know the answer, but I have a few ideas - and one of the most compelling to me is the idea of flow. There are several common uses of the word, and in software development we hear people talk about being "in the zone", where there is an intense focus that leads to a highly productive state where the sense of time disappears and we experience a sense of ecstasy and clarity.

But there is another use of the work "flow" in the world of Lean Manufacturing and Lean Product Development. In this context by flow we mean the direct completion of work from start to finish with as little wasted time and inventory as possible.

I'll attempt to show how these two seemingly unrelated types of flow come into play when we work as a Mob Programming team.

Preposterous? Perhaps, but it's worth considering the possibilities.

What will the audience learn from this talk?

You will learn

• My theory of why Mob Programming is so effective
• The benefits of Mob Programming
• Helpful ideas for helping others understand the benefits of working well together
• The problems that fade away when we figure out how to work well together