Thoughts on agile

This article on agile was going around my company this morning: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

I was originally typing up a response to the email chain, but decided to just make it into a blog post instead.

---

Agile is great as a communication structure. The ticket allocation and review processes can be a good starting point for teams, and the 2 week review cycle has been tremendously useful for me (both at Ionic and in a previous position) for making course corrections and tracking schedules.

But agile is not a substitute for having a plan, and just “doing agile” provides no value by itself - value is useful working code shipped to a client. Process is just a means to an end.

My team does not track burn down or total # stories completed in a sprint, as a way of measuring productivity or otherwise. We track completion of just a few high value tasks per individual, which are called out in planning documents for each 2 week cycle. The tickets are mostly composed by individual team members (getting the team to this position was one of my individual OKRs for this quarter).

The user story concept can be helpful, but just changing your tickets from “make X do Y” to “as a user of X I will be able to do Y” doesn’t make you write better software any more then being able to quickly phrase answers in Jeopardy format makes you smart. User stories are a method of communicating, and the value of various parts of the communication changes based on what is being communicated. (Side note: for a better approach, check out Joel Splosky's excellent series on functional specs.)

The comments about open plan offices are interesting. I did not like the idea of an open plan office when I arrived at Ionic. I agree it is much harder to just concentrate and get work done, so straight line speed is diminished. However, the barrier to conversation is lowered, and there are a lot more chance interactions, which helps grease the wheels of collaboration. However, if I need to get something complicated done, whether doing research or just coding a complex system, I’ll ofen do that at home. I could see this being a problem for people with children where home may be less work-friendly environment.

The idea of "escaping the sprint” is also on point. I’ve been trying to make sure that almost all scheduled work for my team is part of a project with defined start and end points. This has helped us get out of the quagmire of continually patching crappy systems and move on to building what we actually know we need.