in I have a feeling that when there is something about agile, it means scrum or kanban. But it’s not only 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 you will hardly be agile without discussion. To explain what I mean, I just describe two current situations.
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 planning (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 a company in London once in a while, usually once per two months, where we discuss several things:
- I show a 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 that 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 of what should roughly come next to just have an idea. That can help us to better prepare our codebase and architecture. But we don’t discuss it in detail 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. Everybody can go that way without pushing, which is much better if everybody knows the goal.
Those points are, I would say, essential 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 a friendly community with many opportunities to hang out with those people. We use those opportunities because it’s beneficial and vital. In this project is involved a lot of people from many places around the World. It’s becoming harder and harder for any project where you cannot simply go and solve issues face-to-face. But we know why what and for whom we are building that software, and we can make 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 being safe, I mean those details 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 a simpler solution. We had a 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 specifications. We don’t write any specific issues (or tasks or user stories, whatever you want). We really rely on communication. We benefit from the 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 proper specifications (of any kind) which would help us (programmers) understand the problem better. I’m delighted 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. I got a lot of ideas about how it could be better as I saw the first versions. How it could fulfill my needs much better.
I was creating many issues, but a lot of them were 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 the time when I got the idea. But I was an end-user, product manager, designer, and programmer at the same time, so I could decide which issue to 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 specifications and everything… it’s nothing compared to have appropriate communication. If the product owner can explain to you well the goal and why they need some features, then you are free to do it your way and change the decision at any time if the goal stays the 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.
Also, I wanted to say to programmers to not be afraid to work without specifications. I made that mistake before as well. I asked for a better spec, and if there wasn’t a 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 I 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 the following 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 a team needs something different, but communication is the primary tool that has to be there.
P.S.2: Go watch my favorite video describing agile in a nutshell.
P.S.3: If you are curious about what I am building, stay tuned. I will share that soon. :-)
feed