Agile leadership: results

A couple of weeks back I have reached out for help for my MSc thesis about leadership in organisations of different size. I have received 200+ responses overall, and 166 complete, usable responses based on which I managed to complete the following report:

Leadership in Agile

A big thank you goes out to all of you who made this possible. Thank you for your time, response and support; I am really thankful to all of you.

Agile leadership: request for participation

For the past months I’ve been researching what characteristics an Agile Leader needs in companies of different sizes, for my MSc thesis. I’ve now reached the data collection phase. If you are working in an Agile team, please fill out the following survey to help my work. It will not take more than 10 minutes.

In return, I promise to make the results available here on this site, as soon as I finish writing.

The link is here:

Thank you in advance!

Agile != Scrum

“I hate Agile. It’s full of these pointless meetings like planning – which is a complete waste of time.”

I’ve overheard a colleague of mine say this the other morning. Of course, he meant Scrum. Many people think these two concepts are the very same and use them interchangeably. Agile, however, is a much broader category;it contains loads of software development methodologies – one such being Scrum itself. Let’s see a quick (and far not complete) overview: 




The bars above show how heavyweight a process is. The more things prescribed by a methodology, the more heavyweight it is. Scrum is pretty huge; it defines roles, meetings – it pretty much schedules your days two weeks ahead. On the other hand, Lean development only defines principles – like amplify learning – and does not say anything about implementation details.

So if you think Agile is bad (a waste of time, too restrictive, or on the contrary, too permissive), you perhaps just had a not so well chosen process. Take another look, it may worth trying a new agile methodology.

Do sprints add value at all?

Do sprints make any sense at all? We can’t go fully agile, so these artificial deadlines don’t have any added value at the first place.

After having worked on some mission critical software, this is what perhaps I hear the most from agile-skeptic people.

Let’s admit it: many domains are too rigid for sprints, continuous delivery and such. I can’t imagine a telecom company so agile, that it rolls out new software for an entire network every 1-4 weeks. Not to mention several deployments per day. Just imagine it; one tiny bug and the whole network of your provider goes down for hours. Dropped calls, unsent texts, broken 3G connections, apocalypse.

Also, I perhaps wouldn’t like my bank to deploy new software that often. I simply wouldn’t feel my money’s in safety.

What about an MRI software updated every two weeks? One single bug, and it falsely diagnoses people with lung-cancer.

Full agile is great if you are doing stuff people use for fun and not for a living. The worst that can happen there is a “please try again in a few minutes” error message. Maybe you cannot wish a happy birthday to your uncle; he might get disappointed, but no serious damage is made.

The thing is that a good majority businesses are just not suited to be entirely agile. Whatever you do at development, after a certain levels things stop being agile. “No matter” if you keep or break your sprint commitment, because the project as a whole is not to be delivered in two weeks. It’s due date is far ahead in the calendar, half a year, (even more) not to mention its first deployment date. And that’s good. Some thing just need to pass a big number of tollgates to be entirely safe to use.

Is it worth to do sprints and/or continuous (internal) delivery then? Definitely. Creating a complex system is much easier when done in chunks of work; iterations, user stories, tasks. They bring the feeling of getting something done every two weeks, every day, every hour. They also help keeping the focus, staying organized. One task at any given time. Smaller pieces are easier made bug-free and more maintainable.

Even if you can’t save the world (=make agile enterprise-level) the benefits of sprints can be huge if done right. Also, in such tough industries odds are pretty high that there is some kind of complex legacy process in place. As processes are never perfect, sprints offer a pretty fine opportunity to revise them. It “sometimes” even makes people  happy to have their voices heard.

Sprints, put it simple, are an awesome way of getting better stuff out of a team; better performance, better processes, better mood. Maybe it’s time giving them a try?

Kanban board design

Some days ago, I was giving a talk at the Budapest Lean/Kanban meetup group on how Kanban works in my development area. The presentation below captures several Kanban board designs from this development area, along with their pros/cons. As you can see all of them are pretty much different, however, they all work quite well in their own context.

So, take a look if in the mood, and feel free to share your own table designs.

Kaizen on team level

For several months I’ve been trying to convince management to introduce some innovations in order our product to be more stable, better performing and of higher quality. Among those ideas the two most important are already introduced and well functioning at several software companies of huge size. Namely, those are Kaizen and FedEx days (more on those a little bit later).

I don’t think I wasn’t persistent enough. I was trying on several levels. I went to innovation days, used idea boxes, had face to face conversations and so on. The result was always the same. The answer –in each and every case- was, “Wow, these are great ideas, we can really profit from these things. We’re definitely going to try these things out. Thanks for pointing it out”. Unfortunately, for some reasons the implementation of the ideas never took place. Too bad, there’s a lot of nice things about them.

Kaizen is a technique of continuous improvement. In its simplest form, it only needs a whiteboard, some kaizen cards with improvement ideas and some creativity from the team’s side. An idea can be process or technology related. The point in this way of collecting ideas is the infamous (mainly retrospective-related) phrase of “Gosh, I had a great idea, but I can’t recall it”. The idea behind kaizen is something like: any idea is worth discussing, none is worth forgetting. You get an idea, just write it down and put it on the board, so everyone can see it/think about it.

FedEx days are special working days, when no one is allowed to do their normal, every-day work. Instead, everyone is required to work on a kind of own project, with the only restriction that it has to make either the process or the product better. See how things connect? Those ideas collected on the Kaizen board can be developed/introduced during FedEx days. In order to get the best results, these occasions have to be organized regularly (bi-weekly or monthly).

My current team is a newly set-up one. Some people are having hard times understanding the basics of different agile methodologies. At the beginning there were no clear rules, we had a hectic whiteboard and several severe arguments. There was no way of introducing any improvement. The first thing was to do Kanban, with all its principles, practices, board-design stuff and so on. This took some time (and it still goes on. Some people just don’t want to get why Kanban rules are better than chaos. Even if they see data-based results. More on that in an upcoming post).

As Kanban was more or less in place and management was still ignoring the concept of kaizen, I decided to introduce it on team level. The idea was simple: I “designed” a kaizen note template, simple as hell: a table with two rows: idea and benefits:

One day I added a new Improvements section to the Kanban board and made the empty kaizen notes available. And guess what; it turns out that people actually HAVE improvement ideas. And they are keen to share them. This is how the board looked like before the first session of discussing the improvements:

Ideas are discussed; after reading the kaizen note’s text, the author is given the opportunity to clarify any unclear aspects about the idea. After a short debate where everyone can tell their thoughts, a simple majority voting is held. If an idea is passed, it becomes a new team principle. Rejected ideas become buried forever.


Ideas can be real simple and straightforward things. Things like “I think we should implement different classes of services. Benefits: better and faster work”. Improvements should not be thought of as world-saving things. Simple tiny steps can lead to better achievements.


A current state of the whiteboard:

As per now, I can say Kaizen works just fain on team level. Maybe as the project advances (as we’re working on a new,greenfieldproject) we can introduce FedEx days on team level as well. So we could tell managers “see, that’s why we should have it on organizational level”.

Agility and code quality

Some days ago, I attended a meeting, where different projects’ agile people met and talked about challenges, achievements, stuff. Actually it was not the first time we met. The meeting has been held for months now. For these long months, there has been something that was bothering me about these discussions. I couldn’t name that thing, so I stayed silent, but now I think I suddenly recognized it (under a hot shower, sorry if it’s TMI – too much info). After these months it seems to me that people percieve agile as daily stand up meetings + retrospectives (or just the first one, in case of Kanban development). Some of these people are amazed that they’re still getting bug reports in spite they “are doing agile”. Standups: check, retros: check, planning meeting: check, but bug reports, however, still flowing in.

Don’t get me wrong, I’m not against these things. Daily standup is a very important thing. It facilitates communication between team members, or sometimes even between different teams. Daily scrum alone, however, will not make code quality any better. It will strengthen team spirit, it will help everyone to keep track with every aspects of the current development, but it’s not meant to get source code in a better shape.

The same applies to retrospective. It is a very cool forum to talk about strenghts and weaknesses of a team. Even better if constructive ideas arise (by the way, I don’t understand why some people think retrospectives cannot fit into Lean/Kanban ways of working. The process itself can be trailored and developed; for new teams it can be particularly helpful). In my opinion retros are one of the most important meetings of agile frameworks. It’s psychology, I guess. Some people simply won’t tell their ideas, unless they are told to do so.

So, standups and retros (along with other meetings) fail to improve code quality. That’s because agile ways of working  can be divided into two parts:  the process itself and a technological part. The process part mainly contains of the meetings described above, definitions of done, team rules, team members’ motivation etc. One needs soft skills in order to manage/take care of these things. By soft skills I mean empathy, friendliness, motivational skills etc. And all these things will not get you a good quality product. It’s because quality is directly related to technical skills. Technical skills include test driven development, code review, pair programming, design discussions and so on. So, will code review help improve quality? Most probably. You might spot suspicious code lines, liar names, uncovered production code. Will TDD help? Definitely. Your code will be doing exactly what you expect it to be doing.

I once heard of a project where all the soft skills were perfectly applied. All staff members were happy with their work, they have had daily scrum, retros, everything. However, when it came to unit tests, they were like: “well, uhm, our unit tests require a living connection to the database, a writable file system, a network connection …” and so on (remember the definition what does not count as a unit test: a test which touches the file system, talks to a database or over a network. Anything that lives outside of the test runner framework). So even if these guys respected all the soft-skill related part of agile, were producing not so good quality. They were stuck at a low level of technical skills.

So what I’m saying; it makes no sense to apply only one or the other part of an agile dialect in solitude. You need both of them in order to succeed. Soft skills in order to get motivated and happy people, and technical skills in order to produce fewer bugs and maintainable architecture. No process hsould be called agile until both parts are applied, in my opinion.