Agile 101

We’ve talked about what Agile is, where it comes from, and why it’s important. Now we’re going to kind of thrust our hands into Agile and start working on some of the specifics. One of the most important items in Agile is the Agile user story. And this is the centerpiece around which we do this narrative collaboration that I’ve mentioned is so central to the successful practice of Agile. The user story has these three clauses. As a persona, I want to do something, so I can derive a reward. We’re going to learn how to think about who this persona really is. This is a humanized view of your user.

One that’s actionable, vivid, and testable as you look to drive to sources of value. I want to do something that’s pretty self evident and then derive a reward, well what does that mean and when is the future really done? Is it when its not broken, is it when some user says it’s okay, or is it when we see it become relevant and successful in the market? Okay you probably guessed that it’s all three of those and we’re going to learn how to work through those things. Here’s an example of a user’s story. As a social mom I want to see about my Facebook posts so I can decide if I want to go back and look at it.

So they get a text, they get an email, it’s a feature on Facebook, that might have been developed against a narrative like this.

We take these stories and then we sort them into what’s called a backlog for actual execution of software. So, we take our stories and we sort them, in order of priority, and then we cut them off at the amount of work we think we can do in a single iteration. And these iterations are usually two to four weeks, sometimes a little bit longer. Now, you may be thinking, we only release software a few times a year, or that sounds like a very frequent way to get software out the door. But you can batch these up into releases.

So when you finish software, and we talked about the importance of working software as a measure of progress in the manifesto, you’re only looking to validate it internally. And you may want to release it externally and some, putting users in front of it, you need to do whatever has to be done to evaluate the value of the software, but you don’t necessarily need to release it to the public at large. That’s what these releases are for and you may batch several iterations into one release.

How does this actually work? Well, when we do these releases. When we do these iterations, rather. We start from a set of humanized views of who is our user? What jobs are we doing for them? What desires or habits are we delivering on for them? We create these user stories to anchor our view of what’s valuable in a nice, testable narrative about what the user wants to achieve, we discuss these as a product team. Agile teams are small, five to ten people and the stories are not an alternative form of writing a specification. They are a backdrop for discussion, and that is their only job.

Their only job is to facilitate high quality narrative interdisciplinary collaboration, and drive to good decisions about development. Then we work to validate these features in the different aspects that we’ve talked about. Is it not broken? Can we release it? How do users react to it? There’s various ways that you’ll learn about of how to do that and what to do when. The daily stand up is one of the most widely used artifacts of Agile and the idea is that the team gets together and again it’s a small team. Five to ten people on the outside. And they answer, everybody including the managers answer these three questions about where they’re at and what they’re doing.

And this is very focused on output because inside an iteration, you are focused on a specific job that you’ve decided is going to generate some kind of output that you think will lead to a valuable outcome. So the team does this to not only just keep track of where things are going. But more importantly the idea is that Agile teams are self-organizing. The individuals support each other, help remove barriers, decide who should be working on what amongst each other rather than from a strict command and control approach with a singular project manager. So these stand-ups help them do that. And we’ll talk also more about those in course three, Managing with Agile.

The way that we look at progress over the course of an iteration is with this thing called a burndown chart. So the time for the iteration, let’s say it’s 14 days,

we look at that here on the x-axis and then there’s a total amount of effort. The amount of effort is calculated against each story. So we ascribe some kind of rough sizing, like a one to ten scale to the stories. And then we count that up. So if we had 20 stories, with three points each, this would be 60, the total size of the scale. Every time we finish a story, we mark that event on whatever date we had. So let’s say we accomplished 10 points worth of stories on this date here. We would make this mark here on the chart. And that’s how we get this curve.

Here are three of the most prevalent Agile methodologies. So these are sort of sets of specific procedures to implement Agile. We’re going to be focused on fundamentals. Techniques that you can bring to Agile to improve your practice, as an individual and your work within a team. Scrum is on the of the most prevalent Agile methodologies and a lot of the concepts we just went through, came from Scrum or part of Scrum and it is a good set of tools, but, again, the most important thing is are you achieving these good outcomes? Extreme programming is another methodology that actually precedes the Agile manifesto. And it’s more focused on coding methodologies extended forward to project management practices.

And finally Kanban is sometimes presented as an alternative to these In reality it’s a set of methods to reduce work in progress. So for instance, it’s a set of techniques to help us make sure that not all our stories, not all our tasks are stacking up and getting blocked in QA, instead we try to create a nice continuous flow across the stages of completion. So actually, there are Kanban practices and Kanban outcomes that you can measure in these other methodologies as well.