Agile introduction

I need to declare full disclosure up front, if you were to cut me open you would find Agile written through me like a slightly overweight, middle aged piece of seaside rock (hopefully this reference won’t be lost on my non UK readers). With this in mind my early years as a developer were spent frustrated that projects were taking too long, test were engaged too late and the business weren’t engaged at all. I appreciated that a process was critical and we needed to agree what we were to deliver and provide checks against progress but did it really need to take so long and be so disjointed? Over the years I learnt more about the classic problems with large “big bang” (aka waterfall) releases:

  •  In the numerous months between the customer requesting work and receiving it, their requirements had changed due to the speed of change in the real world. This wasn’t the client’s fault they couldn’t have predicted the next 6+ months with perfect accuracy.
  • During this time customers often had very little progress updates and if they did the indicators weren’t always reliable.
  • Dev felt they were too remote from the customer and feared making decisions or had to wait a long time for them to be made.
  • Test acted as game keepers trying to catch the developers out to settle the age old question of who’s better, developers or testers.
  • With a long project plan very little pressure existed at the start. Issues were found and added given the lack of pressure to hit deadlines. Panic only set in towards the end where it became clear that we wouldn’t achieve what had been committed to. We then had the choice of reducing the test duration or dropping functionality and sometimes both.
  • Often things would go wrong and it felt like some people were spending more time building their defence as to why it wasn’t their fault rather than working on a solution

You can therefore imagine my absolute joy when I was introduced to Agile. Oddly it wasn’t alien but simply collected ideas that I had seen working well on previous projects. I need to be clear that there are a number of Agile methods which we’ll be looking at in later discussions but for now a few forgive me a few generalisations. Agile focuses on:

  • Satisfying the customer through early and continuous delivery of valuable software rather than waiting till all deliverables are completed.
  • Work is performed in regular “chunks” or iterations and working software is the primary measure of progress.
  • Business people, developers, testers and analysts work together throughout the project to ensure the project remains valid and provides useful software.
  • Teams are given the environments and support they need to get the job done.
  • The team performing the work are involved with providing consistent estimates to divide the work into iterations.
  • Requirements are captured up front but we only add detail to the ones we’re due to work on in the immediate future.
  • The team are empowered to make the right decisions
  • Quality and validation are built into the process not an afterthought waiting to strike
  • The most efficient and effective method of conveying information to and within a development team is face to face conversation.
  • Any changes to requirements can be supported as long as we all agree and the impact is agreed.
  • At regular intervals the team reflects on how to become more effective, then tunes and adjusts accordingly.

Let’s be clear that Agile is not a silver bullet and won’t be appropriate for all scenarios but now that I’ve given a brief reason to consider Agile my next blogs will discuss, are you ready for Agile, what are the Agile methodologies, myths and facts of Agile, optimal techniques for introducing Agile and optimal development environments.

4 thoughts on “Agile introduction

  1. One thing I also do as a tester is to help the team crtnool scope. Most newbie agile teams over-commit, and they work on stories that are too big. Find ways to divide the work into small chunks or threads. Make sure testing estimates are included in story estimates. Sometimes features take longer to test than to code! When you see a story that looks too big, ask if it can be divided up. Sometimes the smaller piece may not deliver much business value, but the team needs to focus on getting one small story done at a time, including all the testing activities.

    • Good question! I belevie a team is performing SCRUM or it smells like it is doing Scrum! when:a) All SCRUM roles are identified and filled and working in the right way’b) That the artefacts are in place Product Backlog, Sprint Backlog etc and being worked!c) That the team has created and is using a definition of Done’ for each Sprintd) That the team has a project goal and a Sprint Goal and all understand what it isd) That the team is using SCRUM definitions and terminologye) That daily meetings are attended by all the teamf) The team trust each otherAnd the proof is if they are delivering each sprint in accordance with business priorities set by the Product owner .in a nutshell ,,,

    • That’s so true! I’ve had very similar experiences. Another blog will probably have to be classic mistakes and how to avoid them. Many thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *


+ 3 = 10

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=""> <strike> <strong>