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.

Developer to Manager Pluralsight Course now Live

I am pleased to announce that my first Pluralsight course, Developer to Manager, is now live and available to watch for all Pluralsight subscribers. You can view a demo of the course below.

The course is based off an article I wrote earlier this year called Transition from Developer to Manager. This has been the single most popular article on this blog. I frequently receive emails from people asking advice on moving into a supervisor / leading role, so I hope this course will help everyone who watches it.

Stephen Haunts Pluralsight Author Page
Stephen Haunts Pluralsight Author Page

The course will start off by covering what a typical supervisor / management role looks like and its aim is to set the listeners expectations about the role to help them make an informed decision. The course then goes on to help the listener come up with a 90 day plan to help them make a real impact in the role if they choose to make the leap.

The structure of the course is as follows:

Module 1 : Introduction

Module 2 : What Does it Mean to be a Manager?

Module 3 : Your Team

Module 4 : Your First Month

Module 5 : Your Second Month

Module 6 : Your Third Month

8 Leadership Traits for Software Development Leaders

I was reading a good article the other day in INC magazine by Aaron Skonnard, who is the CEO of Pluralsight, who I have recently started Freelancing for. The article is called How to Build a Kick-Ass Exec Team, and talks about 8 leadership traits company heads / CEOs can use to create a good working culture within their organisations.

The article is aimed at people who run their own companies, but I thought the leadership traits Aaron talks about also apply to other leaders and managers lower in an organisation. From my point of view I am thinking as a Development Manager running a software team in a healthcare organisation.

8 Leadership Traits for Software Development Leaders
8 Leadership Traits for Software Development Leaders

In this article I want to covers the original 8 leadership traits and say how they apply to managers and leaders of a software team in an organisation, as I feel there is a direct correlation. I recommend reading Aaron’s original article first.

Leaders Help Their Teams

The team I leade, I try to run agile using Scrum. I say, try, because the project I am currently running is part of a larger program of work that is very much waterfall. We are one of the donor projects in a larger agile transformation plan. As part of the running of this team I want to avoid being the guy at the top dishing out orders or even worse, Micro Managing. I believe a team should be self organising in their workload with inputs from the product owners and business who guide our direction. My role is very much about removing barriers and blockers that get in their way so they can concentrate on doing what they do best, developing software. I feel it is much better to be a servant leader as opposed to a more traditional autocratic leader who controls a strict hierarchy whilst leading from the top.

Transition from Developer to Manager

Since writing this article, I have developed a training course for the Pluralsight training library called “Developer to Manager” which is available to all current subscribers.

There comes a time in every developers career when you will have to make a decision about your own progression. Do you stay as a developer / senior developer and focus mostly on code, or do you make a jump into a management level position as a Lead Developer who has to manage staff or a Development Manager.

Dilbert : Programmer to Supervisor
Dilbert : Programmer to Supervisor

I had this same choice back in 2011. I was a Senior Developer for a large internet bank. I didn’t directly manage any staff although I was a mentor to a few. I got involved with an academy program where we would offer work placements to university students and train them up for a year. I started on this program as a mentor, but eventually I ended up running the academy as-well as carrying on with my normal role as a senior developer. This was my first proper go at directly managing a team of people, and I really enjoyed it. From there I moved onto my current role (Current for the next 2 weeks of writing as I accepted another job) at a consumer finance company as a Lead Developer. This role still involved some coding (but no where near as much as I was used too) but focused mainly on leading a multi disciplined team of software developers.

It has largely been a good experience for me and I enjoy leading as-well as coding, but it isn’t for everyone. Seeing as I am about to take on a new role as a Development Manager for a new organisation, I thought I would put an article together on making the transition from Developer to Manager based on my experiences. I hope that it will help anyone who is trying to decide whether it is the right career change for them.

How to Motivate and Innovate Part 4 : Leadership Styles

In the previous articles in this series I covered Motivation, Finding meaning in your work, and how to encourage innovation in your team. In this final part of the series I want to discuss some different leadership styles you can adopt with your team.

There are many different types of leadership style you can adopt and rarely does one size fit all. Sometimes over the lifetime of a team you will need to adapt your style to fit a certain scenario, or use a specific style with different people on the team, especially if they are persistent under-performers.

You need to adapt your leadership style to different scenarios.
You need to adapt your leadership style to different scenarios.

Bureaucratic Leadership

Bureaucratic leaders are people that follow rules to the letter, and they ensure their team follow rules and process to the letter of the law. If you are working in an environment where safety both to people and systems is essential then this type of leadership style is needed.  If you have a team that does a lot of repetitive and manual work, then this style is also very well suited. If you want your people to be creative and innovative, then this isn’t the best style. You can use a blend though where you slip into bureaucratic leadership if you have a strict deployment or change management process to follow.

Dieter Rams : 10 Principles of Good Product Design

Since I wrote my article recently about Google’s 9 principles of innovation a reader over on Reddit pointed me to a resource on some more good design principles. These are the 10 Principles for Good Design by a German industrial designer Dieter Rams.

Dieter Rams : 10 Principles of Good Product Design
Dieter Rams : 10 Principles of Good Product Design

Dieter Rams introduced the idea of sustainable development and of obsolescence being a crime in design in the 1970s. Accordingly he asked himself the question: is my design good design? The answer formed his now celebrated ten principles.

Whilst Dieter was an industrial and product designer, his principles can fit anywhere where good design comes into play. In the rest of this article, I will explain what the 10 principles are, and how I think they fit into software development.

The principles in this article are very useful for software developers and designers, but this is also very relevant for technical leaders. As a leader it is good to try and push your teams to make sure they are thinking about the end user. Traditionally, software developers make lousy designers (not all of them before I start a flame war), but aesthetic design, generally, isn’t something that comes naturally to programmers. Therefore having principles like these is great for giving you pause to reflect on how your system / application affects your end users.

The different product images below are examples of products designed by Dieter. Those of you old enough may recognize a few!!

Google’s 9 Principles of Innovation

Whilst doing my daily trawl through the internet and Reddit pages, I came across a very interesting talk at the San Francisco Dreamforce Summit where Google’s Chief social evangelist, Gopi Kallayil talks about Googles 9 principles of innovation. Please do go and watch the video as it is a great insight to the inner workings of Google, but here are the 9 principles summarized here.

Googles 9 Principles of Innovation
Googles 9 Principles of Innovation

Innovation comes from anywhere

An idea for an innovation doesn’t have to just come from your super star employees. Ideas can come from anyone. There is a really good example that Kallayil mentions where an onsite doctor at Google had idea that if someone talks about suicide in a Google search that the first item in the search results should be the phone number for the National Suicide Prevention Hotline.  The call volume to the helpline went up 9% after that. This is a great example that an idea for an innovation, no matter how small, can have a big impact.

Google's automatic reference to a suicide hotline.
Google’s automatic reference to a suicide hotline.

Due to the impact of this one small change, they have now rolled this type of change out across the world. In the screenshot above you can see where it shows the phone number of the Samaritans.

How to Motivate and Innovate Part 3

In the first 2 articles in this series I talked about what is motivation and how developers can find meaning in their work. An effective development team is a team that is engaged in their work, feels as though their contribution is valued and that the work they are doing has real benefit for the business.

In this 3rd part of the series I want to talk about innovation and how you can encourage it within your teams. Being able to innovate is something every developer should want to do, but you need to control the innovation process properly otherwise you can end up with a team just doing their own thing and taking their eye of the ball for the business.

Encourage your team to innovate solutions.
Encourage your team to innovate solutions.

What is Innovation

Innovation is the application of better solutions that meet new requirements, in-articulated needs, or existing market needs. This is accomplished through more effective products, processes, services, technologies, or ideas that are readily available to markets, governments and society. The term innovation can be defined as something original and, as consequence, new that “breaks in to” the market or into society. One usually associates to new phenomena that are important in some way. A definition of the term, in line with these aspects, would be the following: “An innovation is something original, new, and important – in whatever field – that breaks in to (or obtains a foothold in) a market or society.”

Definition of Innovation from WikiPedia

As the quote above says, innovation is the application of better solutions that meet new requirements. I believe it is important to try and foster a culture of innovation in a software development team as your developers (I am including QA’s, UI designers, and anyone technical in this too) are the brains behind your companies systems. Innovation can come in many forms. It could be an idea for a completely new system, or it could be an enhancement to an existing system or process. If your innovation could end up taking a large amount of time to implement, maybe you can do a proof of concept first to sell the idea to your management or business sponsors.

I want to give an example of a recent innovation that has come from my team and talk about how it has benefited the business. This is an example that ended up being a large revenue generator, even though the actual ideal was quite simple and didn’t take that long to implement.

How to Motivate and Innovate Part 2

In the first part of this article on motivation and innovation for software development leaders, I talked about what motivation is, how your working environment can affect your motivation, and how to get into the zone whilst working.  In this 2nd  part of the article I want to discuss some of Edmond Laus’ Strategies for finding meaning in your work from his blog post, “What research on happiness and motivation can tell us about finding meaning in our work.”, and how Me and My team have applied some of these strategies.

Strategies for Finding Meaning In Your Work

In Edmond’s his article he proposes 5 strategies for finding meaning in your work. I want to list them here with my own thoughts, but please check out his article to get his own thoughts on them.

Validate new ideas early and often with simple proofs of concept

This strategy really speaks for itself. Before investing a large amount of effort into something that may not work out, you should try out a proof of concept first. Generally a proof of concept will be a throw away piece of code just to prove whether a theory will work or not. When my team write proof of concepts, they don’t even bother writing unit tests for them, as the code is never destined to be production code. You can even take this POC idea further by following some of the Lean Startup ideas and produce a larger working mock-up of a system, or a minimum viable product as described in the book.

The Lean Startup - Eric Ries
The Lean Startup – Eric Ries

We tried this in my team. We had a project that our debt recovery department wanted to initiate, which is a self-service portal on the web to allow customers who are already in debt to make a payment online, and therefore avoiding a difficult conversation with our debt collectors over the phone. The idea made a lot of sense, but before investing a large amount of money in building the portal, we did a lean start-up style set of experiments to test the theory against a minimum viable product.

%d bloggers like this: