Agile is a buzzword. These days, everyone is “doing agile”. Or so they say.

Despite over 90% of senior executives stating agile adoption as a top priority, less than 10% actually consider their firm to be performing with a high level of agility.

As much as people love to wear the badge of agile on their sleeve, there is a great deal of confusion swelling in the dark chasm between the aspiration of agile implementation and reality.

So what is agile?

It’s basically a philosophy of software development that prioritizes iterative development of working software and solutions through cross-collaboration and self-organizing teams.

It’s also an umbrella term for a bunch of development frameworks, but agile doesn’t simply mean kanban or scrum.

Some of the confusion arises when teams equate the agile approach to using an “Agile framework” (usually capitalized).

Frameworks like these are attractive because they’re sold as simplified solutions to difficult project and process management problems.

Sure, these frameworks can be an important part of an agile implementation, but they need more. They need a firm foundation to stand upon.

It’s not enough to simply go through the motions and expect an agile approach to “just work”, especially when transitioning from a more rigid and traditional framework like waterfall.

In order to drive agile success, teams need to adopt agile philosophy. They need to change the way they think about work ownership, management, and their relationship and duty to customers.

Without this vital force, frameworks like scrum and kanban fall flat.

In this article I’ll investigate what it is that separates true agile from the “fake” agile that is often the differentiator between success and failure of a development team. Here’s a quick overview:

• What is fake agile?
• Why fake agile is bad for your teams
• Fake agile vs true agile: How to spot the difference
• Misguided agile leadership
• Understanding true agile
• Questions to ask to help you spot a fake agile team
• The need for agile training
• Tools for agile teams

Continue Reading

This article is a guest post from Dillon Forrest, a front end developer, startup guy and content creator. Follow him on Twitter for more posts.

If you’ve ever wondered how to attract and retain engineering talent, this post is for you.

Engineers are notoriously difficult to find, screen and onboard. Every candidate who receives your job offer has likely received several others too. And once they do accept, it’s only a matter of time before another company tries to poach them.

It’s time to ask yourself if your developers are really happy, or are your company’s development processes driving them away?

Let’s take a deep dive into the world of Daria the Developer, discussing five common workflow problems, and giving you tips on how to manage developers.

Continue Reading

The way customers see it, your software release cycle looks like this:

• Take ages developing the software
• Beta test
• Add a few features, fix a few bugs
• Done!

This isn’t real life. Beta testing is only one type of test your software needs to pass to avoid being a catastrophic failure.

If your software is struggling to get into a usable state, it’s probably because you’re overlooking testing.

Testing is important for two main reasons:

1. Tests will reveal flaws in your software
2. Tests will reveal flaws in your software development process

Note: Apart from customer-facing and QA tests, tests are code.

So, keep reading to find the types of software testing you need to make mandatory in your development team, as well as an explanation of how to do it.

Continue Reading

If you’ve been reading our content about the importance of processes, you know the kinds of things that happen when standard procedure isn’t followed. Satellites crash, nuclear reactors melt down, and information security disasters ruin huge corporations.

For software companies, failure doesn’t always have such wide implications but it can mean carelessly shipping a product that creates catastrophic problems for your customers and destroys their trust in you. And of course, it’s a pain in the arse for your development team to fix.

In this article, I’m going to go over some famous software disasters where Quality Control dropped the ball, and look over some common quality control methods.

Continue Reading

Get Ready to Swat Those Bugs and Up Your Development!

Every programmer and developer makes mistakes. That’s not a criticism by any means; only a couple of posts ago an eagle-eyed user spotted a Freudian slip of mine when “baring” something in mind. Not only is it a vital part of improving in your field, but the freedom to take risks and leave errors also allows the best of the best to flex their muscles and get creative.

I mean, just so long as it doesn’t almost cause World War 3.

“The necessity of selecting and following a formal process for software development is to… avoid wastage of time, money, demoralization in developers, etc.” – Harisha K R

That’s where your software development processes come in! Here at Process Street, we’ve helped to show how processes can boost productivity, save money and all-around improve your business. So, after showing how to ace your IT processes, we’re here for another round to give you the run down on software development processes!

Take your pick from any of these ready-to-use checklists to easily execute your debugging, sprint planning, user story grooming and more. The wild world of software development awaits!

Continue Reading

The following post is a guest contribution from Steve Klein the co-founder of StatusPage.io.

How long does engineer onboarding last at your company? 1 week? 2 weeks? A couple months? Regardless, it’s a process you think about in the short term, right when a new employee starts. Once it’s done, it’s done, and you can go on to thinking about the million other things that are going on in your company. Right?

Wrong.

The effects of employee onboarding last way beyond when a new person starts working and impact your whole company. If your onboarding isn’t effective, in just 1 or 2 generations of hiring you’re dealing with a team that’s shockingly less productive than it could be — and costing you a lot of money.

Continue Reading