It doesn't have to be scrum

I have a feeling that when there is something about agile, it means scrum or kanban. But it's not just that. It's definitely one way how to be agile, but it's not a synonym. The most important thing about being agile is communication. You can actually use any system (at least I think so) but without communication you will be hardly agile. To explain what I mean I just describe two current situation.


First from my day job: I work with a small team on a project which should help to build a better Internet. We have no planing (as described in the scrum), no stand-ups, no boards, no retrospectives, no regular meeting. But everything works very well and in a very agile way. I visit company in London once in a while, usually once per two months, where we discuss several things:

  • I show demo of what we have done since the last meeting and then we discuss how it met (or not) their expectations.
  • What should we focus on for next month or two. They explain in detail what they need and why. That “why” is very important because thanks to that I can offer maybe another “what”. Something what can fulfill their needs much more or something similar which will cost much less money (or effort if you want).
  • They also update their view what should roughly come next to just have an idea. That can help us to prepare better our code base and architecture. But we don't discuss it in details because always those details change during the next month or two. Always.
  • Also, we share a long-term view to have the same focus in mind. To not be lost in details and not forget what we are building. That's important so nobody needs to dictate who will do what and how. If everybody knows the goal, then everybody can go that way without pushing which is much better.

Those points are, I would say, very important to be agile. Of course, we do more. Another very important for us is to visit people for whom we are building that project. We are lucky that it's actually friendly community with many opportunities to hang out with those people. We use those opportunities because it's very useful and important. In this project is involved a lot of people from many places around the World. Any project where you cannot simply go and solve issues face-to-face, it's becoming harder and harder. But we know why, what and for whom we are building that software and we can do a lot of decisions alone.  

Anyway, there will always be many situations when we just don't know. In that case, we prototype. We create some base structure first and then we add as many details as we know are safe. By safe I mean those details which are very easily changed or there is a small chance we will throw it away. That's very important because to show example is much easier than to describe anything. This way we simplified a lot of things; for example, there was a very complicated feature and we weren't sure why it has to be so complicated and created a mock-up of simpler solution. We had problem to explain it, but when we showed it, that solution won immediately.

I think it's clear, but to be exact, we don't have any specification. We don't write any detailed issues (or tasks or user stories, whatever you want). We really rely on communication. We benefit from knowledge of why and that we know our users. And I think it's much better for both sides than any specification. I haven't seen in my life good specification (of any kind) which would help us (programmers) to understand the problem better. I'm very glad that we just discuss everything and then we (developers) create issues in our issue tracker.


Second, my home projects: I had two ideas in the last months, but I didn't know how exactly it should look like or even how exactly it should work. Well, I just started with a base structure. Some mock-up with proof of concept that it can work. As I saw first versions I got a lot of ideas how it could be better. How it could fulfill my needs much better.

I was creating many issues, but a lot of them was just not worth to do it. I would spend a lot of time doing them and would bring me as much value as others. That's something not even me knew at time time when I got the idea. But I was end user, product manager, designer and programmer at the same time so I could decide which issue do first and which later and which just ignore very quickly. I could decide that in milliseconds. Actually, I could change the way right away, but the main goal (without specification) stayed the same.


You probably see what I'm trying to say. If you will focus on all meetings and proper specification and everything… it's nothing compared to have proper communication. If product owner can explain to you well goal and why they need some features, then you are free to do it your way and change decision any time if the goal stays same. I'm not saying not doing scrum or other agile techniques, I'm saying that those regular meetings have some meaning, to bring this communication. Just bringing those meetings to the team doesn't mean anything.

I wanted to also say to programmers to not be afraid to work without specifications. I made that mistake before as well. I was asking for better specification and if there wasn't good one we're complaining and it was also our excuse for many problems. I was so wrong! I could see thanks to my last two projects that even me was unable to create a specification. It was much better to create a functional mock-up, try to use it, change it and continue with next details and features. Finally, I'm not afraid to delete the code. To be a better programmer, don't be as well.

P.S.: Of course every project and team needs something different but communication is main tool which has to be there.

P.S.2: Go watch my favorite video describing agile in nutshell.

P.S.3: If you are curious about what am I building, stay tuned. I will share that soon. :-)