Speaking at DDD North, A Free Community Software Development Conference

In this video, I talk about a trip I made to Bradford to speak at the DDD North community event. I also discuss the subject of speakers being paid for talking and why I am happy to talk at community events like DDD North at my own cost.

The talk I did at this event was my Scaling Agile with the Spotify Model talk. If you want to see a version of this talk, I have my recording from NDC Oslo this year.

Advertisements

Life at a Start-up : Structuring teams for growth (NDC Oslo Talk Video)

As well as being the head of development for Buying Butler and RightIndem, part of my role is speaking at technology conferences around the world. I speak about many subjects around technology, but I do this as a representative of the company, which helps us spread the word about what we are doing.

In June I went to Oslo in Norway for the NDC conference where I spoke about restructuring teams using techniques that were first described by Spotify. We have tried to adopt something similar in our company, but as with everything Spotify’s technique is not one size fits all. The main message from my talk is that you have to adapt the model to fit your own companies structure and requirements.

In the talk, I discuss how Spotify have done it, and also how we have tried to implement it.  The key difference is that Spotify is a B2C (Business to Consumer) company and we are a B2B (Business to Business) company.

I am thinking of writing a more in-depth article on this, but for now, I will leave you with my talk from the conference. It is the first time I have done the talk, and it seemed to go down very well with people. I had lots of people come and see me afterward to ask me about it in more detail.

Speaking at DDDNorth

Stephen Haunts speaking at DDDNorth
Stephen Haunts speaking at DDDNorth

I am pleased to announce that I will be speaking at this years DDDNorth community conference about Lean Software Development. This is my first DDD event so I am looking forward to it. The conference is a free one day event that is being held at Leeds University on Saturday 1st October. Here is my talk description.

Lean software development (LSD) is a translation of lean manufacturing and lean IT principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community

In this talk we will look at Lean Software Development and how it is a benefit to modern development.

We will start off quickly looking at Waterfall and Agile, and then look at the history of Lean and its origins at Ford and Toyota. From there we will show how leans applies to software with the following lean principles:

Eliminate Waste

Build Quality In

Create Knowledge

Defer Commitment

Deliver Fast

Respect People

Optimize the Whole

We will then answer the question Agile or Lean and then look at different software practices that will help support your use of lean including Kanban.

The talk would be aimed at software developers who are keen to apply lean to their software projects.

 

Lean Software Development Fundamentals on Pluralsight

I have recently released my latest Pluralsight course called Lean Software Development Fundamentals. The course is an extension to my Agile Fundamentals course and talks about applying some of the principles of Lean manufacturing to the software development world.

Lean Software Development Fundamentals by Stephen Haunts
Lean Software Development Fundamentals by Stephen Haunts

Here is the official course description.

Incorporating lean manufacturing and lean IT principles and practices is essential to delivering software to your customers quickly and easily. This course, Lean Software Development Fundamentals, will help you understand how the lean principles can be applied to software development so that you can more efficiently deliver software. First, you’ll look at how the seven lean software principles apply to a software development team. Next, you’ll discover what practices a team can introduce to help make the transition to lean easier, and how Kanban can help to make a team more efficient. Finally, you’ll also get to think through a fictional example of a software development team delivering a call center application to their business. By the end of this course, you’ll better understand how to develop your software in a lean way, and ultimately, you’ll be able to deliver with increased efficiency.

Agile Fundamentals Course Now Live on Pluralsight

My new course, Agile Fundamentals is now live with Pluralsight. The course description is as follows :

In Agile Fundamentals, we explore how working on an Agile project has benefits for your development team, your end users, and your organization as a whole. This course starts by exploring the more traditional waterfall process, and then covers why running an Agile team is a good idea. This course is ideal for software developers, project managers, software leadership, or anyone that would have an interest and gain benefit from running an Agile project and delivering maximum value early to your customers.

The course is split into the following modules :

1. Introduction

2. Waterfall Development and It’s Problems

3. What is Agile all About?

4. Common Agile Misconception

5. The Advantages and Disadvantagesof Agile

6. Extreme Programming

7. Scrum

Advantages and Disadvantages of Agile Software Development

I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.

In this article I want to cover some of advantages and disadvantages of agile software development. I have already written a number of articles about agile development, agile misconceptions, agile benefits and common mistakes make by new agile teams.

Advantages and Disadvantages of Agile Software Development
Advantages and Disadvantages of Agile Software Development

Advantages of Agile

Customer Satisfaction by Rapid, Continuous Delivery of Useful Software

Your customers and users will be satisfied because you are continuously delivery value to them with usable software.

This is a stark contrast compared to that of a traditional waterfall product delivery, that if your customers are used to waterfall, they may find it strange adjusting to having working software sooner.

The big downside of waterfall is that you deliver large pieces of functionality towards the end of the project life-cycle. This means that all throughout the development stages of waterfall, your project is incurring costs with no return on investment.

By delivering working pieces of functionality sooner and more regularly you are giving your users an opportunity to get a return on their investment sooner. Sure, they may not have all the functionality they need upfront, but they can start to make use of the solution to make their lives easier and start realising the benefits sooner.

Common Mistakes Made by New Agile Teams

I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.

I have already written a number of articles about agile development, agile misconceptions and agile benefits. In this article I want to cover common mistakes that are made by teams new to Agile. They are in no particular order and are all equally as relevant. Not all teams make all of these mistakes, but these are observations I have seen over my career.

Common Mistakes of a New Agile Team
Common Mistakes of a New Agile Team

Fear

Fear is a powerful emotion that is encountered in many forms. For a team new to agile this is fear of the unknown as working agile is completely different to that of a more traditional waterfall process. Fear drives bad decisions and practices that can frustrate a new Agile team. The enemy of fear is trust. You counter fear by instilling trust at all levels.

Start by letting the team know that the organization trusts them to make the right commitments and decisions. The team should be trusted to learn, grow, and make choices as a group, instead of taking directives from management.

A common example of fear stifling team growth is the issue of commitment. Teams often under commit or pad their estimates, due to fear of being responsible or blamed for failure. Initially, allow your team to give themselves permission to miss in their estimation. Foster an environment of trust, such that the team can explore the causes of a miss without finger-pointing.

This will help you find the true limit of your teams velocity. A single miss should translate into dozens of future successes.