A Complete Guide To Agile Product Development: Everything You Need To Know

“We’re a software company, we should go with Scrum .”

The first time I heard this statement was from an ex-colleague of mine at a financial institution where I worked as a System Analyst. Not sure whether he meant it as a joke or not, but to me it sounded like the right thing to say if you wanted to get out of doing any work. So I left it at that and didn’t think about the statement again until colleague number two came along with the same line of thinking, this time however he wasn’t joking. After mulling over his words for a while, I started to see some sense in what he was saying.

I later went on to become an Agile Coach, so now I’ve heard just about every justification imaginable as to why companies feel they should adopt Scrum or another Agile methodology. The truth is there are many misconceptions around Agile; unfortunately many of these misconceptions are fuelled by those who already have preconceived notions (i.e., Scrum zealots). To make things even more annoying they all seem to have different explanations for each of their own misconceptions. It is as if there are multiple Agile Methodologies with no shared values or principles, so I thought it may be helpful to simplify things and break the information down into a list of points that sum up what Agile Methodologies are and aren’t.

Agile isn’t a process – If you think about any other methodology such as PRINCE2 , MSP , etc., these could all be considered processes, yet we don’t refer to them as such. Scrum however seems to wear the badge of ‘process’ like a merit award from school – “Hey look, we can move cards around!”

An excuse not to plan – Planning is a very important stage of completing any project, and this is true with Agile as well. It is just that the planning stage occurs throughout the whole project rather than being done in isolation at the beginning.

A solution to all of your problems – We all know how it feels when we see a friend with a specific problem and our immediate reaction is “Oh you need my Agile Methodology!” Let’s not be that person.

History – Every method has been developed from where we have come from as an industry, so whilst Scrum was developed by Jeff Sutherland and Ken Schwaber , changing requirements were becoming more frequent due to technology advancements which brought about frameworks such as eXtreme Programming . What makes a good methodology? So now that we know what Agile is, let’s ask ourselves “What makes a good methodology?” So now that we know what an agile methodology is, the next question I (and probably you) want to ask is “What makes a good methodology?”

The industry trend – As previously mentioned, technology advancements lead to more frequent changing requirements. People wanted software faster, which meant they needed people to work on it faster. This inevitably meant that companies had to implement methodologies that allowed teams to develop and deliver quickly and efficiently. The result? Methodologies such as Scrum . Making it work, the hard way: Things like project management and development methodologies exist because someone or something created them for us; however this rarely means we won’t make mistakes when adapting them to our situation. This will be particularly true if we try and force parts of the methodology to do things they weren’t meant for, or less true if we take them and apply them as is.

The fact is, ideally we should develop a methodology that fits our own needs and way of working; at least that’s what Leslie says. The book shows us how to modify Scrum in order to work in distributed teams; however I’ve seen people (usually wanting to stay away from official methodologies such as SCRUM) start their own processes like these: The “It worked at my previous company” approach: They find a process that works somewhere else and make it fit their needs.

More often than not this results in a lot of wasted time doing the wrong thing, which they blame on the new process. The “We are different” approach: This approach is usually more harmful than helpful since it implies that what works for the majority of teams out there won’t work for them. While this may be true in some cases, more often than not they have just found another excuse to avoid adapting their processes. The “Agile” approach: It’s always funny when people use this word as an adjective to describe whatever methodology they’re using. I’m pretty sure people trying to do Scrum with Kanban or vice versa are just missing the point about what Agile really means.