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.

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.

What are the Business Benefits of Being Agile

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

Lots has been written about the benefits of Agile methodologies and Scrum for the development team. Articles about the agile manifesto and scrum have encouraged developers to think about iterations, user stories, backlog items and delivering value with rapid defect feedback, but at the end of the day, what’s in it for your business?

Agile has Many Benefits for the Business
Agile has Many Benefits for the Business

In this article I am going to think from the businesses point of view. What’s in it for your business? They don’t really care about iterations, continuous delivery, unit tests and all the other good stuff us developers love. They care about their business and competitive advantage. Especially if there is a danger of a young start-up being disruptive and stealing market share from under your feet.

Technical Debt Analogy

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

I was reading a book called ‘Software in 30 Days – How Agile Managers Beat the Odd, Delight Their Customers, and Leave Competitors in the Dust‘ by Ken Schwaber and Jeff Sutherland , and there was a fantastic analogy that summed up technical debt, which I wanted to quote for you here.

As technical debt grows it becomes harder and more expensive to fix over time.
As technical debt grows it becomes harder and more expensive to fix over time.

In cold climates, when the temperature drops, the pipes in houses often start knocking. Whenever you turn the water on at the tap or use the washer or dishwasher, whenever the heating system starts up, the pipes start banging against one another, against the framing, and against the walls. Sometimes they sound like a jack-hammer, especially when they start knocking in the middle of the night. Knocking pipes are hard to fix. They rattle because they weren’t properly secured. When they become loose and knock, precisely locating them is difficult.

The knocking may be happening at a different place from the insecure pipe. Over time, they become looser. It is difficult to find the exact place where they should have been secured, as the noise may be located a short distance away. Frequently, you have to make a large hole in the wall, remove any insulation, and start looking. Then, with a little luck, you can secure the pipe properly. The cost of securing a pipe correctly when it is installed differs minimally from securing it incorrectly. The cost of securing it once the building already has been constructed is much higher.

There is a powerful lesson here in that you should try to build your software as best as possible from the start. If you start making compromises in the design and testing, then you will create technical debt which you will have to pay back later, but you always end up paying it back with a lot of interest.

Velocity is Not a Goal or Target

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

I was listening to an episode of the DotNetRocks podcast about Agile Metrics. There was an interview with Michael ‘Doc’ Norton about his experiences figuring out the right metrics to measure for the productivity of a development team. The basic issue discussed was that Velocity is a dangerous metric to rely on as a goal or target.

Agile Velocity is a Dangerous Target
Agile Velocity is a Dangerous Target

Velocity is a measure of units over time, so in an agile iteration or sprint, that would be the number of story points completed in the iteration. This is a dangerous metric because it is misleading to management. One week, your team may complete 10 story points in the iteration. Management may then say,

“Well, that’s great, if you can better that to say 12, we might finish early.”

The team, then starts their next sprint, aiming to complete 12 points, but they end up only completing 5. This is like a red rag to a bull to management, but this could be a valid scenario. The velocity of 12 from the previous sprint may have been achieved because all the development tasks where contain within the development team. If as part of the next spring you need input from other teams or departments, then this could affect your ability to get work done as planned. This just one example of an external influence affecting velocity, you could have people go of sick, on holiday, or anything else that can happen that is out of the teams control.

It is because of these external influences that the velocity metric becomes a bad metric to rely on. There is just too much variability in the numbers from sprint to sprint. This doesn’t mean you should ignore velocity completely, but managers should not ask teams to hit targets based on velocity.

%d bloggers like this: