Quick Bytes: Do you have experience with agile?

Agile Interview Questions

Agile Interview QuestionsIt’s impossible to be a Java developer without experience agile in one of it’s many forms.  Stemming from the agile manifesto which originally launched in 2001, agile practices took the software world by storm to quickly becoming one of technologies biggest buzzwords, which it still is today.  The problem is, many if not most agile projects have little or nothing to do with agility, instead becoming an excuse for poor design or instead allowing clients to demand more output at a faster pace and for less.

 

This makes agile a very interesting interview question from both sides. Chances are you have experience in a project which claimed to be agile, but was it really? Can you recognise the strengths and weaknesses?  Agile questions also give you a great opportunity to understand a teams development practices.  Are they the real deal, or have they just added two week sprints on top of waterfall? The maturity of a companies agile practices can be a good indicator of the quality of it’s systems.

 

What is Agile Development? How does it differ from other methodologies?

Agile development acknowledges that software projects are very different from building projects where more traditional development methodologies came from.  It is entirely possible to know up front exactly you would build and design a house; you can perfectly spec the size, shape and design up front. This allows you to perfectly plan what work is required and how long it will take based on previous experience: putting a brick wall up with a window is a standard practice wherever you do it.  Software is not like that. System development is complicated and difficult, but more importantly the end user does not normally know what they want or they are incapable of explaining it.  If you take 6 months to write a full specification and a further 12 to build the system it is often out of date by the time it is finished and won’t actually meet the needs of the customer.

Agile development acknowledges up front that requirements are malleable and that there will be unknowns. Being able to respond to change and produce a working, valuable system is our primary goal.   There are a number of features of agile development which help to achieve this:

  • Iterative development: a minimum viable product is produced to get a system in the hands of the user.  New functionality is added and the system improved using the feedback of users.  This minimises the time between a user requesting a feature and being able to use it live.  In turn this helps to prioritise the features which will add the most value for development next.
  • Stakeholder interaction: One of the central tenets of agile lies in the close interaction of development and business, working as partners on the solution.  This requires commitment from the business to spend time on the project but ensures a higher quality solution. In other methodologies such as Waterfall where the requirements are agreed up front lead to IT being a service and the solution rarely matching the needs of the consumer.
  • Product Backlog/Planning: The work for the coming weeks or months is written as stories; these are chunks of work which can be usually completed within a single iteration (usually lasting 2 weeks).  Features can be prioritised by the business based on rough sizing (such as t-shirt sizing). Features with higher importance can then be broken down into detailed stories.  Only the work for the upcoming iterations should be well understood with detailed stories, as this reduces the chance of wasted planning because of a change in priorities. Agile embraces change.
  • Velocity: By measuring the size of stories (either in time, story points or some other fashion) we can see how many of that unit we can complete each iteration.  A well performing team will “burn down” a similar amount each sprint, allowing for a team to be able to estimate upcoming deliveries with a reasonable degree of accuracy.

Where agile tries to incrementally develop and deliver a product, Waterfall instead focuses on creating all the requirements up front and delivering the system as a “big bang”. This rarely works.

Tell me about your experiences with Agile. Do you think it’s a good thing?

Obviously this is going to completely depend on how your teams have worked, but the important thing is to take the time before an interview to think about your experiences and come up with a concise opinion.  Here’s my view.

In principal, agile development is a great thing. It’s certainly lightyears ahead of waterfall and other legacy methodologies.   There’s a big difference between lowercase agile and uppercase Agile.  Lowercase agile is about actually being agile: flexible, nimble and open to change. This is a rare thing though, as most firms use the formal uppercase Agile.  It has garnered a worsening reputation in recent years.  A lot of people have used the banner of Agile as an excuse for poor development practices; skipping out on design, poor planning, completely abandoning documentation.  The most common practice in my experience seems to be to continue to do Waterfall; big requirements up front, but then to do two week “iterations” without any flexibility or interaction with the stakeholders.  This is obviously a bad thing.

Further to this, things like Scrum have further damaged the reputation in my opinion. It places formal process around the intentionally loose agile manifesto, which can add significant overhead at no benefit in an undisciplined and untrained team.  Scrum master certification has removed all value in the term “Scrum Master’ thanks to greedy training companies allowing anyone with money and a weekend spare to become certified.

For me, good agile can be represented simply as “iterative development” and working closely with my stakeholders.  Each team and each project works differently and it’s important to come up with something that works for you.  Being able to react quickly to changing requirements and deliver brilliant, functional systems is the most important thing for an agile team.  This doesn’t preclude up front design and this doesn’t stop documentation.

I’d love to know what you think.  What is your experience with agile, or indeed Agile?  Let everyone know in the comments!

 

5 Comments

  • “It’s certainly lightyears ahead of waterfall and other legacy methodologies. ”

    Sigh. “legacy”. A word filled with nuance. The fact of the matter is that EVERYONE does waterfall, even when they are calling it Agile. Almost NO ONE does Agile.

    • So much this! I completely agree. However this fact seems to be a dirty secret. If someone came to me in an interview and said this I’d give them a big thumbs up for being aware and able to articulate it.

  • Thanks for the article and putting up it in simple words. Do you think if agile can be applied to enhancement of software where possible number of unknowns are higher?
    Also how does someone address technical limitation if discovered while following agile.

    • Hi Ashutosh,
      Agile is best when the possible unknowns are higher. That’s literally why it exists. How can you waterfall plan a project with so many unknowns? It’s not possible. Agile allows you to deliver the minimum possible value and then iterate on it. It’s a journey of discovery, and it means you can’t go too far in the wrong direction whilst your discovering unknowns.

      As an aside, all projects are full of unknowns. It’s impossible to do a perfect spec, which is why waterfall consistently fails.

      I think that also answers the technical limitation part; fundamentally everything is possible (within reason). If you discover something that takes much longer than you thought it would, or will be very expensive, the owner or sponsor of the project needs to prioritise whether to continue the work or change direction.

Join the Discussion

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>