The first time I’ve heard about “agile” in relation to IT project I thought about yet another buzzword that does nothing to what I did back then. It was 2008 and It was my second job in IT. Before I was working as an IT administrator which basically meant that I was doing everything from installing Windows XP on workstations, maintaining Novell Netware server as well as an awesome Windows NT machine with state of the art tax application installed on it (yep, that was sarcasm).
My work routine was like this: I got to work in a morning, reviewed if backups were there and were valid. Checking emails and then proceed with my personal to do list. This list involved improving stuff in our infrastructure, implementing Bacula as a primary solution (xcopy was cool, but it wasn’t enough).
Nobody I knew was talking about HA, clusters or how to organize our work to be more effective. Yet, I was performing quite well and changed directions of my personal objectives when needed. I was doing “agile” and didn’t even knew about it.
W… what the heck are you talking about?
Agile. Or agility during software development. Dave Thomas says it’s dead, but maybe not entirely.
Back to my story.
Fast forward to year 2016. I’m working in multi-national company with couple of scrum teams. We work following variants of Scrum and Kanban (bare with me, will explain in a moment) and we love the experience. Every two weeks, we try to do a small change in our in-team process to be better at what we do. It’s hard and involve a lot of discussion. Sometimes we need to take a step back when something is not working. But in general, we’re efficient and flexible. I like to think we do a very good job.
So Agile Manifesto is there since 2001, here you can read about Agility a bit more. Scrum I mentioned before is a variant of agility in software development which involves more structure to how things are being done: there’s planning phaze, the summary (retrospective) phaze and a sprint (a time box in which you say will deliver some functionalities). On top of it there’s a lot of other things you may or may not want to implement.
The other way: the kanban mode
Kanban on the other hand comes from the 1950s from Japan. It’s been developed to top-up production efficiency. Yes, it wasn’t made for software development. The main idea is to lower delays, queues, idling and any other technological operations. All of it was made with a little help of cards with relevant information, passed through every involved division. Kanban in software development looks similar. First you get the pool of ideas (also known as a backlog), then you put it in the queue to “process” by a developer, kind of request to provide a feature. Then developer grabs it, and put the card in “In progess” field until he or she is done. After development, if your organization cares about code quality and knowledge sharing, code shuld be reviewed. Then it should go to testing phase (quite often it’s a testing environment, like local system, then QA system, pre-production system and then production). It’s good practice to have up to three cards in development by one person.
If it comes to systems engineering (or operations, or ops), I experienced both Scrum and Kanban to be a good choice. Although keep in mind that Scrum is better for established environment where you don’t have many fires (or, ideally, any) because it’ll break the sprint (which means you won’t make it to deliver all features you planned). Kanban allows you to be more flexible, you can drop anything you’re doing now and create new card with task to extinguish fires and then get back to what you were doing later.
And it doesn’t end here. You can apply agility for your project in your own unique way but having in mind to keep some basic principles that will help you maintain your quality and overall effectiveness as high as possible.
There’s more: One guy (Allan Kelly) wrote a book about cross over from Lean, Scrum, Kanban, Extreme Programming and various other principles called Xanpan. It’s been effectively implemented in organization he is working for and apparently it works for them. I can’t believe it works perfectly 100% of the time, but it’s effective enough for them.
So why would you apply it?
First of all: it’s hard to do it. If it was easy to apply high software quality, everybody would do it. It won’t be like you flip the switch and everything starts working from the day one. The change, as usual, have to be applied gradually in small steps.
As I see it, it’s all about approach to work organization, not only in IT industry (see Kanban). If you are able to plan, execute and measure progress, then most likely you’ll find some weak spots to be fixed in next increment. And as work progresses, your organization will become better and better at it.
So if you care about your project and organization, then you’ll seriously rethink how you make things work right now and if it makes sense to grab some ideas from Scrum or Kanban or whatever you think sound sane to do.
Now I can tell you where it won’t work. Or when it’ll be extremely difficult to implement.
Does it scale?
Let’s take an organization with dozen of external clients, small group of developers (say 12) and approximately 20 different projects that come and go. Scrum won’t work here because sprint would be broken forever, or you’d have 20 sprints at the same time and 20 daily scrum meetings. That even sounds ridiculous. Not to mention that 12 people team is too big for a Scrum team.
You’d have to have 20 Kanban boards if you consider Kanban. In this case it’ll be difficult to talk about priorities and keep track of everything.
It’s of course divide all those 12 developers to 20 teams, but you probably realized just now that some people in development teams would overlap. That would be hard on them, not to mention about motivation aspects.
It is however possible to organize work to be less stressful and more efficient. Besides expanding your development team that is. I’ll write more about this case next time as this post got quite long.
Worth it or not?
In short? Yep. Do it!
But be patient, make sure whole team knows why and how will you do it. Make sure they all know all, and I mean all the reasons why you change things for them.
I mention that because a lot of people don’t even try to get the basic principles and think of daily scrum as a humiliating experience where they have to tell (I’ve heard about “confession” the other day) what they are working on. You must understand that it’s not their attitude but misunderstanding the “why” in the process.
Another thing is “how?”. You should allow team work this one out. The hard part would be have team actually make the change. Again, if they don’t see the reason why they should challenge status quo, you pushing for the change will fail one way or another.
There are books about those methodologies, but I will say just that: If you want to be good at what you’re doing, you need to learn from better than you, so read, talk to other people and organizations, ask questions and listen. This will give you ideas about next step to being great.
Here are some basic ideas about implementing agility.
This should help you get started.