Agile software development is one of the most popular yet most
difficult ways to develop software because really everybody has their own flavor of doing it. Well in this video
I'd like to share with you seven common pitfalls that I see people run into all the time that cause projects to fail.
Hi, I'm Jayme and at Healthy Software Developer, I want to help you stay calm on your software projects,
I want to help you make sure that you can actually keep growing and not get stuck - and you can have a healthy work-life balance.
I've been using agile software development with teams for over 15 years and as a
consultant in the last 10 years of my career
I was often brought into big companies that had really big problems with their software development process. And so today
I'd like to talk a little bit about the most common pitfalls that I've seen and you can look for these on your
projects, and if you come across these you can try to remedy them. The first common problem
I see all the time on agile software development projects, and this is really common especially at big enterprises, is a company
that's trying to use really high friction tools. And what I mean by that is
when a team's first trying to do agile of any sort whether they're doing Scrum
and they're trying to release things in sprints or iterations or they're using something more fluid like Kanban,
there's so many tools out there that can be used development tools for the team,
project managers, product managers, the ops team to try to manage work and manage when people get things done. And
oftentimes I'll come into a company to help them and I'll find they're using let's say JIRA or some other tool and
whoever's configured that tool to help them do agile development, It's created a situation where just to record
let's say a user story or just to mark off that somebody's done with work takes
you know somebody fifteen minutes or something like that.
And
if you have a tool that's really high friction like that, first of all you're gonna lose a lot of time to just using the
tool. Second of all is I've found a lot of teams
people on the team will just
refuse to use the tool or they'll really hate working with it. And so your process is really only as good as the people that
are gonna follow it. And the other thing is I'll find that
oftentimes people will just try to use every bell and whistle in their tool to do agile software development
and then all this data is collected, and they don't even use all that data. The second failure
I see all the time on agile software development projects
and this is just a problem in our industry unfortunately, is when people expect all the team members that are on a project to work
exactly the same way.
I personally am pretty comfortable with writing documentation and user stories and writing my own acceptance tests and acceptance criteria
but I've found you know on many software development teams sometimes
you'll have a person who really loves to code, but they honestly just hate the tools they hate documentation.
And there's other people that might like to do code reviews and other people that don't. And I've been on many projects where it's really
mandated that you know "this is the process let's say or the set of steps"
"we're gonna go through" that the team's agreed on and "we're gonna just expect"
"everybody to follow that". and usually in my experience at least that doesn't really work very well.
So one thing to look for if you're on a project that's trying to do agile for the first time,
or maybe you've been doing agile for a while again Scrum, Kanban, any flavor under the sun - and
people on that project aren't really working together in the same ways you might take a look again at your software development
process and think a little bit about: "Am I maybe being a little too"
"rigid with the decisions that have been made?". And this doesn't matter if a consultant came in and helped
you know you decide what process steps you're doing or it was maybe done by a lead developer or a whole team of people or
a project manager.
But you know putting in place an agile development process that allows people to work differently and work at what their
strengths are and not focus you know so much on everybody trying to basically work and follow the same steps
exactly the same way
oftentimes can actually help a team be more productive.
It's very counter intuitive because you know the way we're raised in the school system and the way
a lot of corporate America and the rest of the world likes to look at it is that
you know "we need to get everybody to conform,"
"we need to get everybody to measure things and do things the same way".
But at least in my experience, that doesn't actually create a healthy team where people can really be creative and really be productive.
The third thing I often see teams struggle with on agile software development projects is a really important one
but one that people forget all the time, and that's to really stop doing what isn't working.
An example of this is, I've actually been on teams where they have a daily stand-up meeting,
which is really common on scrum projects and in that meeting
where you're supposed to ask and answer the three questions right like what did you do yesterday?
What are you gonna do today?
And do you have any blockers? The team is so tight already and so small maybe it's a three developer team
that's using the daily stand-ups
that every single morning
meeting is really a waste of time because maybe they're on slack or they sit right together in a set of cubes.
And so following that you know process from scrum and doing that isn't really helping that team,
it's not really buying them anything and this is just one example. So you know I
caution many people when I come into a company try to help them
and I caution you as well, that if you're trying to adopt agile software development processes
you definitely don't have to follow by the book everything that let's say the scrum guide or some training or
certification you went to says is necessary. If it's not really providing value for your team -
stop doing it. The fourth problem
I see a lot on agile software development projects is when the team focuses on
collecting data and analyzing it over teamwork.
This is really common on projects where agile software development processes have been kind of mandated by the business or
managers, and they're not really being driven by the engineers, or the operations people, or UX people - people that actually do the work
where the rest of the business looks at agile as a way to get more information about how
efficient the software development team's working. And so often that can result in the software development process how its put together
is optimized and set up just to help
management make decisions. And obviously it's important that
management can have an idea of how progress is going and what's going on and what people are working on,
but if the processes are tilted too far to that direction it can actually slow the team way down.
And you don't even get the benefits of agile software development, which is supposed to be the ability to actually change direction at any time.
The fifth problem
I see that's really common on agile software development projects is when a team is measuring output instead of
outcomes. So in the 90s when people first started doing scrum and things like that a lot of people sold
agile software development methods to the industry or their boss as "this is a way we can get work done quicker"
and it was really kind of missing the point of the agile manifesto
which are really (I'm sure you've heard about them) the different principles that a group of people came together and said
"these are the principles of agile", and they're not really
prescriptive, they're just overarching ideas that people should follow. But
unfortunately there's many teams out there
and I talked about this in my "secret of scrum" video, that they will use agile
methods just to try to put pressure on people to try to get them to produce as much features
or as much code as possible within a short period of time.
But that code
that's produced, or those deliverables that the team is actually putting out there aren't really resulting in more money for the business, or better
satisfaction for the customer. The sixth thing I see cause many agile software development
projects to fail is when a team fails to hold
retrospectives, and this is actually something that came from scrum.
But a retrospective is basically a
meeting that a team, a software development team has every once in a while where you get as many people that are involved in delivering that
project together into a room and they talk about what went well,
and what didn't go well, and some action items about what they're gonna improve going forward. Now on a scrum team
where your let's say delivering a new build of your software every two weeks
it's pretty easy to schedule these you can just schedule them at the end of that two-week period. But on a team that's doing
Kanban where the work is more fluid and things are just taken off a queue and worked on immediately,
you need to have you know a product manager a team lead somebody that actually
schedules a time where the team is regularly getting together to talk about how the project's going. I find if people don't do this
what ends up happening is there's usually a problem with some step in the process.
Let's say the team is writing requirements that just aren't very good,
or maybe the test coverage is just too low to really about be a benefit, or you know somebody's really struggling
let's say just with some aspect of the design or the software development.
If people don't get together regularly as a group and talk about the status,
not just of the project of stuff getting done like you know "how is everybody doing with their features, is everybody getting stuff completed",
but just have a chance to get together and be really honest and transparent about "You know what, over the last two weeks"
"we didn't do a very good job of" let's say
"automated testing" or something like that or "You know what, over the last two weeks"
"we didn't really have help from ops enough to make sure that our"
"releases were pushed out to production in a smooth way. We need to figure out a way to improve that."
Without that regular rhythm of holding retrospectives all that stuff has to happen sort of
"from the hip" and
coordinating all that can be really difficult. And often you know when I've been in the
situation where I'm just a developer on a team whether I'm an architect or whatever
but I'm not really responsible for the project or the product,
I don't really have enough time to help everybody to the level that I'd want. And if there isn't some scheduled time to hold a retrospective,
the situation just never improves. And the seventh common problem, I see with agile software development projects is
when a team doesn't release their work regularly. So one of the
key principles of the agile manifesto is this concept of
continuously releasing value to customers. And the first few agile projects I worked on back in gosh
2004,
2003 when it was still pretty new in the industry and there was not nearly as many tools,
you know I was on a team that would build
software every two weeks, but we would get together at the end of the two weeks in a room
we'd show you know the product owner or the product manager what we built we'd get some feedback.
But then we'd just call it "done", and start working on the next two weeks of work. And that work
we just completed never even went out to the customer.
And so if you're gonna actually get a return on investment, and by that I mean the company is gonna get a return on
investment for the work that you do, it has to actually be released to production and go out to your customers.
And this is really where continuous delivery came from this concept of
building an automated system that will push your changes out as a team is done with them on a regular cadence.
So if you're on a team that's building things and iterating and constantly marking deliverables off as "complete",
but they're not actually getting released to users,
unfortunately you're actually delaying feedback from customers about what's going well,
what could be improved, and what needs to change - which is really what's gonna cause what I talked about before:
Positive outcomes for the project where the the project's making the company more money.
And that's what's really gonna result in the ability for you to get promoted,
you know people to get rewards and raises and
everybody at the whole company to be more healthy about how they can reward people and make sure people are growing in their careers.
So what are some pitfalls you've run into on agile software development projects?
Leave me some comments below. If you're new to my YouTube channel please subscribe and click the bell notification icon,
you'll actually be notified every time I release a new video.
You can also listen to this instead as a podcast on Google Play, Stitcher, SoundCloud or
iTunes. So until next time,
thanks.