Being Agile

How to build an Agile software engineering environment

Andy Kimbrey
Jan 2, 2019 · 10 min read

Hi, I’m Andy, and I am an Agile Evangelist. Being an Agile practitioner means I think Agile is the best way to make software, and being an Evangelist means that I’ll tell you about it!

So what is Agile? Essentially, it’s exactly what the dictionary says: being able to think and move quickly, being well coordinated, and being able to adapt to change. It's a type of software engineering that wants to deliver fast, and often.

So what is Agile? Essentially, it’s exactly what the dictionary says: being able to think and move quickly, being well coordinated, and being able to adapt to change. It's a type of software engineering that wants to deliver fast, and often.

I don’t get on with frameworks like Scrum, LeSS, SAFe, and so on. Taking an off-the-shelf framework and saying “this is how we’re going to work from now on” never works: the business’ needs should inform how the software is developed, not the other way around. I see Agile as a toolkit full of ceremonies, artefacts, and processes to choose and customise to how your business works. In this article, I aim to show how to build a simple and straightforward Agile environment.

For example, the most elementary entities required in software development are the Customer (the entity that wants the work done) and the Team (the entity that does the work). I won't assume the presence of a product owner (who could be the customer) or scrum master (who could be one of the team) as these aren’t strictly necessary, especially with a very small team.

I also promise not to use any jargon! I really don't want to explain a bunch of technical terms to a Customer when we already have perfectly good plain-English words that we can use.

Morning Meeting

First out of the toolkit, let’s take the “daily scrum” and remove the jargon by calling it the Morning Meeting. Having a touch-point for the entire team every morning is a good idea in almost every job, even if it’s just a friendly catch-up, and I’d recommend it for any business.

Every meeting should have a purpose and an outcome, otherwise it’s just a chat. The purpose of the Morning Meeting is to identify problems and the outcome is a list of actions to fix these problems. If the meeting goes off-purpose, anyone may ask to “take it outside” where a smaller audience may go into in details without unnecessary people.

Notice the language here: “problems” instead of “blockers”, “take it outside” instead of “take it offline”, even “fix” instead of “resolve”. It's much easier to communicate when we use everyday language.

I don’t insist on the Scrum format of “what I did yesterday and what I’m going to do today” or force people to stand. This isn’t the army! All we need is a quick, general update from everyone and a list of problems. Every problem must have an action and be assigned to a single owner, who should report back in future Morning Meetings.

I usually hold these meetings at 10:00AM to give everyone a chance beforehand to check emails, deal with urgent issues, and most importantly to grab a coffee!

RAID Log

Now we need to keep track of these problems, so let’s reach into the toolbox and grab a RAID Log, which is basically a spreadsheet tracking our problems until they’re fixed. It needs to be a “living” document which everyone can access, and it shouldn’t be possible to save over someone else’s changes. Something like Google Sheets or Excel 365 is good for this.

The minimum required of columns in a RAID Log are:

  • Type: Risk, Assumption, Issue, or Dependency;
  • Name: a short description of the problem;
  • Description: why this is a problem; and
  • Owner: the person responsible for fixing the problem.

I like to include the next action to be taken towards fixing the problem and the last update time as well, but we can add as many columns as we need.

Let’s put the RAID Log on display in the Morning Meeting so we can discuss and update it live in front of everyone.

Requirements

Now we need some work to do! This comes from the Customer (the entity that wants the work done) in the form of requirements, and we’ll call them Requirements instead of “user stories” because that’s what they are.

First, let's find somewhere to keep these Requirements. Like the RAID Log, this must be a “living” document that can't be overwritten, so this can also be a Google Sheet or something more advanced like JIRA. The only necessity is that the Requirements can be re-ordered easily. Let's call this location the “Backlog” of work.

I don’t force Customers, who are usually non-technical, to write in any specific format like a “user story”. The important things to capture are a) what needs to be done, and b) why. The “why” part is especially important so the Team understands the context of the work they are doing.

The next important thing is the priority of the Backlog. This isn’t the order of development, only the team can determine that because they know the technical dependencies. My favourite way of prioritising is the MoSCoW principle. To help the Customer, let’s prioritise in order of Time to Market (how fast they want it live) as in my experience, “minimum viable product” means different things to different people. Priorities should be decided by the Customer and the Team together so everyone is on the same page.

To keep on top of this, let’s have a weekly meeting between the Customer and the Team, and let’s call this the Weekly Prioritisation Meeting (not “backlog grooming”). In this meeting, we simply go through the Requirements and add or update their MoSCoW rating. If done well, this can take as little as 10 minutes per week.

Definition of Done

When we deliver, we want our software to be complete, so we need a clear contract between the Customer and the Team describing what it means for the Requirement to be Done. I usually go with:

  1. The developer has no more coding to do
  2. The code has been peer reviewed and approved
  3. QA have tested it and certified it bug-free
  4. The artist has seen it and agreed it looks like it’s meant to
  5. The Customer has seen it and agreed that it meets the Requirements

This definition can be bigger or smaller than this depending on the project, but it is imperative that the definition of Done isn’t just “the coder pushed it to master.” This is not Done!

Development cycle

Now, how do we get this work done? I’ve always disliked the word “sprint”: it actually means that the Team are full-on smashing out work for a month or two, followed by a period of “downtime” to catch their breath, clear up technical debt, write up documentation, and all that good stuff. We have no right using the word “sprint” to describe 2-week iterations with no breather in between: you can’t sprint indefinitely!

As an Agile Team, we want to deliver often but every week is probably too much, which is why 2-week iterations are most common. Let’s call these Fortnights, a British word literally meaning 2 weeks.

Sizing

So how long is this work going to take? Estimating work is hard! Assume every estimate has a 50% margin of error - seasoned developers will call this conservative; if a 1 hour task runs over by 50%, no problem, it takes an hour and a half, but if a 3-day estimate runs over by 50%, it takes almost a week. This is not good.

There are several ways to tackle this, but none are perfect. One way is breaking down Requirements into smaller tasks which are easier to estimate. This often improves accuracy: I've seen Requirements estimated at 2 weeks shrink to 3 days once the Requirement is properly analysed.

Let's take a look at “story pointing” from our toolbox. Using this method, the team estimates how complex a Requirement is rather than how long it with take. Put another way, they estimate how “big” a Requirement is.

Let’s use Size to describe complexity: a task can be small, medium, or large, and some may be extra small or large. Assuming Requirements increase in complexity exponentially, let’s enumerate these sizes using the Fibonacci sequence as follows:

  • 1: Extra Small (XS)
  • 2: Small (S)
  • 3: Medium (M)
  • 5: Large (L)
  • 8: Extra Large (XL)

Finally, let’s add “I have no idea”:

  • 13: Unknown (U)

“I have no idea” means the Requirements aren’t fully understood or the Requirement is too big, and in both cases needs more input the Customer for clarification or to break it into multiple Requirements.

Let’s call this process “Sizing” and let’s do it once a week like the Customer does when they prioritise their Requirements. Sizing should involve the entire Team to get input on how complex the design, coding, and testing is all-together. My favourite way to Size is gamifying it with Planning Poker.

The purpose of the Weekly Sizing Meeting is to Size all the Must Have Requirements. After that, the Team can move to the Shoulds and Could Haves (even the Won’t Haves if there is time). Especially at the beginning of a project, the Team may have hundreds of Requirements to Size, so let’s limit or cap (not “timebox”) the meeting to an hour. If the Team can’t Size all the Must Haves in this time, the Customer should order them top-to-bottom in the Weekly Prioritisation Meeting to make sure the most important Requirements get analysed first.

Velocity

I think this is as close as I get to jargon. Velocity literally means speed, but it could be called workload or “scope of work”. The Team’s Velocity is how much work they can get Done in a Fortnight, which is measured in points. For example, if our Velocity is 25, we could commit to getting 4x XS/S, 2x M, 1x L, and 1x XL Requirements Done in a Fortnight.

There’s no easy way to predict Velocity at the beginning of a project, the Team just have to guess and adjust as the project develops. This usually takes 2-3 Fortnights to get an accurate estimate, but ultimately becomes a more precise way of estimating work than in hours.

Now we have Sized Requirements and a Velocity, let’s put these Requirements into upcoming Fortnights in the Weekly Prioritisation Meeting. These upcoming Fortnights then becomes the Roadmap, which can be sent as part of a weekly report to all Stakeholders.

Reviews

The most important part of the Fortnight is the Review (not “retrospective”) because this tool helps celebrate success and identify improvements. I only ask “what did we achieve” and “what can we improve”. We don’t need a “what went badly” section; anything that went badly should be an improvement, and every improvement should be logged as a Requirement in the Backlog. For this reason, the Customer or their representative must attend the Review to understand the need for investment in improvements so they can add them to upcoming Fortnights in the Weekly Prioritisation Meeting.

The outcome of the Review should always be sent to the Team and the Customer to a serve as a contract to implement the improvements raised. I also like to add a section called “and special thanks to...” in the Review for the Team to thank anyone not in the meeting. I stole this great idea from my friend and former colleague Agnes Andrasi-Pinter (thanks Agnes)!

Demos

The Demo is also very important to the Fortnightly development cycle as it allows the Team to show the Done work to everyone and get feedback, which could be constructive criticism, praise, or new ideas to add to the Backlog as future Requirements. This also lets the Customer and the Team see their project taking shape every 2 weeks, reinforcing the constant stream of delivery that we’re aiming for.

Let’s add a link to the Demo in the Review report so that everyone can see our progress, and to show off our work. We’ve earned it!

Briefing

In the Scrum Guide, they say “sprint planning” meetings should last no longer than 4 hours, which is 10% of a week, and can include estimating, analysing, and prioritising all together with the entire team. This can be very inefficient if, for example, your developers spend 30 minutes discussing a tricky server configuration while the artists sit there doodling in their sketchbooks, which has happened to me all too often.

Luckily, we don’t actually need a planning meeting because we’ve already Sized and prioritised the Requirements into Fortnights, so we just need to Brief the Team on what’s coming up this Fortnight. This gives them a chance to ask questions to understand the context of the work which is usually very brief (pun intended) so let’s combine this with the Demo and Review into a single, less-than-an-hour-long meeting to close-off one Fortnight and start another. Let’s call this, you guessed it, the Fortnightly Meeting.

For good measure, the Customer’s and the Team’s representative should meet a day before the Fortnightly Meeting to check there are no last-minute changes and lock down the next Fortnight of work. Then we can add this Fortnight’s Requirements to the Review report, and we have a nice email to send to all the Stakeholders every 2 weeks to keep them up to date.

All together now

To recap, let’s look at our Agile environment so far:

Artefacts

  • Definition of Done: a contract describing the conditions needed for a Requirement to be Done
  • Backlog: a prioritised list of Requirements to be Done
  • Roadmap: the Requirements to be Done in the upcoming Fortnights
  • RAID Log: a list of all problems to be fixed

Processes

  • Prioritisation: assigning MoSCoW criteria to Requirements and adding Requirements to upcoming Fortnights
  • Sizing: assigning Requirements a complexity rating
  • Review: identifying achievements from last Fortnight and improvements for future Fortnights

Ceremonies

  • Morning Meeting: 15 min/day
  • Weekly Prioritisation Meeting: 15 min/week
  • Weekly Sizing Meeting: 1 hour/week
  • Fortnightly Meeting: 1 hour/fortnight

Pretty simple, right? Barely any meetings, and we didn’t need to use any spooky language!

And finally

This is, of course, a skeleton of an Agile environment. We didn’t talk about acceptance criteria, deployment, milestones, and all that good stuff; but this is a good starting point to introduce the benefits of Agile software engineering without scaring off your Customer with strange words like “backlog grooming”.

I’ll leave you a final thought: the definition of Stakeholder, which I haven’t talked about yet. Some projects make the mistake of thinking that Stakeholders are just the Customer and their ever-demanding Board of Directors, but it actually includes everyone with a stake in the project, including the Team. You’d be surprised how many times I’ve seen a developer come up with a great product feature, or an artist come up with a creative way of testing something, or a BA coming up with a great idea for a logo. The most successful projects are the ones where the Team are empowered to be Stakeholders and the Customer is part of the Team: that’s where the magic happens, and Agile software engineering makes that possible.

Andy Kimbrey

Written by

Project manager and agile evangelist from London, UK. Also a gaming adept, armchair scientist, philosophy graduate, Star Trek nerd, and Oxford comma enthusiast.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade