Closing Thoughts

Final thoughts of an already long article.

That's the core of agile development business and planning practices. It's been quite the journey. Thanks for sticking through it! I have a few final thoughts on some topics that didn't fit into the page flow or that are not worth the time for the basic reader. You may want to skim the topics below and see if any peak your interest. Otherwise, best of luck on your agile development endeavors! If you have any comments or critiques of this article, feel free to harass me.

Deadlines

Inevitably, someone (maybe even yourself) is going to be utilizing agile development as a method for combating deadline management. And, to some extent, it is. However, agile development will not help you through unrealistic deadlines that are fast approaching. Instead, I have an article for other solutions to deadline management that may or may not be helpful.

Topics I ignored

There are several Agile or Scrum topics that I didn't touch on. Mostly because I either don't think they provide significant value or that they are best melded into already mentioned concepts. If you want my opinion on each one, well, here you go.

Burn-down chart

A burn-down chart is essentially a way to visually see the progress you make on a milestone with the goal of eventually "burning down" enough of the work that there is nothing left to do and the task is complete.

I've never seen a burn-down chart actually help anyone. Sure, they're pretty to look at and give a sense of accomplishment to the engineers and control to the product managers, but their benefit is superficial and usually outweighed by their inaccuracy as you continue to add more wood (tasks) to the fire. Even worse, they are often used as a forecast for when a project will be completed, and forecasts have a tendency to turn into artificial deadlines and commitment. Lastly, a burn-down chart encourages teams to work on one feature set (story) at a time, which is not very agile.

Epics

An epic is the aggregate of user stories that define a feature set. I've been lying to you this whole article though, which makes epics even more confusing. I've been defining a user story (or milestone) as essentially what an epic is. That's because what Scrum states a user story to be is actually a task.

The reason why Scrum calls a task a user story is that a task should be user-centric because Scrum wants all tasks to be focused on how they provide value to a customer. I think that's an understandable desire, but in practice, it is very limiting and nonintuitive. Engineers have a pretty good idea of how to define the work they need to get done. Forcing it to be phrased to be user-focused is simply busy work.

So why do I prefer calling epics user stories? I think the term "epic" doesn't add anything useful to the conversation and is nonintuitive. Fancy names are not very useful when I'm trying to bridge communication between engineers and other departments.

Retrospect & mid-iteration review meetings

A lot of Agile teams will have a lot more–and a lot longer–meetings than those I recommended in this article.

For example, the mid-iteration review meeting is used to review where the team is at with the current iteration and whether or not tasks need to be punted, or given new estimates. That sounds like to me you're just having two smaller iterations within an iteration. It's probably because you have a 2-week iteration. Why not just have a 1-week iteration with no mid-iteration check-in?

There is also the iteration retrospect meeting, which happens at the end of the iteration to review it. I've simply rolled that up into the iteration planning meeting (as the end of one iteration is simply the start of another). Much of the retrospect meeting is devoted to demoing what has been accomplished. I think that's best left for when you are actually prepping for a release. Otherwise, engineers are wasting time each iteration ensuring they have something presentable. Having to have your development efforts on display every iteration can be exhausting and time-consuming, as by default, you're probably in the middle of something and it's likely fairly broken.

Scrum Master, Iteration Manager, Task Manager

Agile and Scrum typically have an assigned member of the team devoted to orchestrating the agile development efforts. They drive iteration planning, make sure tasks are properly created, and help other team members better practice agile planning.

I like giving a task manager role to an engineer. It's good that engineers have responsibilities outside of pure development tasks. I don't have a strong opinion though on how you define or allocate this responsibility. It's going to be tied to your culture.

Agile certification

"The Agile certifications that exist are a complete joke and an utter absurdity. Do not take the certifications seriously." - Clean Agile. Robert Martin, the father of Agile.

Purpose > measures > method

There is an ideology known as Systems thinking (or the Vanguard method) that I'm going to attempt to summarize without butchering it. In essence, people tend to start with methods, which then define their data (and therefore their measurements), which shape their outcomes, which–in turn–shape their purpose. This is backwards. If you let methodology shape your business then you aren't solving true customer needs. It's tradition for tradition's sake. It's best to start with what your purpose is, what your mission is, and the value is that you bring to your customers. Let that define what you should measure and shape your outcomes. Then build methods around it to support the purpose and measures.

I agree with that. Yet, I just spent the last several pages teaching you method instead of purpose. In fact, this is one of the greatest arguments against agile development: it's applied with broad strokes to all software businesses. So why did I teach you method instead of purpose?

For one, there's already an incredible resource that goes into purpose. Clean Agile. Read it, please! Second, there is a competing ideology known as the Dreyfus model that I think trumps the Vanguard method in this case. That is, when we're learning something new, we start by learning the rules. Once we know how to apply the rules, we start experimenting with them, customizing them, and pulling them into contexts as needed. Only after following, applying, and experimenting with the rules do we understand how they can be adapted to our needs.

If you are already deeply familiar with agile development, you are not my target reader. My target reader needs to have tools, methods, and rules given to them to even start the process. Once you have a firm grasp of the tools, then you should take a step back, revisit your purpose, and see what still fits and what needs to be altered or discarded.

Choose your own adventure

I tend to write very deliberately and it may seem like I think there is a strict way to apply agile development. In fact, it's just the opposite. I hope the topics I covered are a great starting point. I hope that you take what you learned here and alter it to fit your own team's needs and culture.

The biggest pitfall regarding agile development is assuming there is a single "correct" way. If you forget about the higher-level vision of what the agile methodology provides, then it becomes work for the sake of work rather than an actual benefit to your engineering teams. You should talk with your engineers frequently to ensure whatever method you employ works for them. Feel free to alter your agile processes across different teams. Yes, it's best to keep consistency across an org–as engineers tend to move between teams and will also need to collaborate across teams–but it's also true that every engineering team has different problem spaces and may need different tooling or methods for optimal efficiency in that space.