Lean Beliefs

Tag Archives: management

The art of micromanagement

Agile, Management / ,

Don’t get me wrong. You should do as little of micromanagement as possible. However, I have a seemingly counter-intuitive theory about how to do it if you have to.

Most people micro-manage in a tactical way: you have an urgent deadline, and you start pushing people. Even if you are an anti-micromanager, when things get critical, sh** starts flowing down from top to bottom, and you get in the way. However, if you do your job as a leader well and empower people (and anyway, they are grown-ups, so eventually they will learn that when things are serious, they have to put „all hands on table” and overcome the problem), your involvement can be minimized.

However, just because of this, due to all the mini-crises along the way, even fairly autonomous people tend to lose focus and strategic topics get behind. I’ve realized in the last half year that this is where a little management attention really helps. In our team, I was able to achieve much more with things that pay off only in longer term, such as highly increasing our activities in fully automated software testing or improving the quality of our product documentation from good to excellent, via a slightly bigger push from my side compared to what I would’ve considered „Agile” before.

As this is something I’ve started to learn only lately, it might turn out that people can be effectively autonomized even regarding long term endeavors. We’ll see, and of course I hope this will happen.

Desperate IT recruiters

Management, Software Engineering / ,

It is a cliché that IT recruiting (searching for great software engineers, system administrators etc. to be hired) is a Payne in the a*s (© Chris Kuzneski). The situation has been quite desperate so far but now it seems getting even more so.

Just 2 examples:

In one of the very freqent regular LinkedIn spams recently something stood out. An US company is hiring IT people in big numbers, all positions being offered to be as telecommuting / remote / virtual jobs. This phenomenon is of course not quite new: for example 37signals / Basecamp (the company of iconic DHH – the Ruby on Rails guy) or Automattic (the company running wordpress.com, about which Scott Berkun wrote an excellent book: The year without pants), and probably lots of other startup-like companies have been doing this for a while. But the company I saw offering this recently in big numbers seemed more like a mid-sized software company. I wonder if this would work well for them, but my first thought was like WOW.

The other example, which is even more radical, can be learned from this article. Simply put: they are paying money to people just to show up on job interviews. WOW^2.

Making Lean and multitasking good friends via GTD (in a controlled way)

Agile, Lean, Management / ,

Lean says: Ideal batch size is one, and we should have Work-In-Progress (WIP) limits all over the place, as small number as possible, in order to minimize multitasking. The reason: multitasking is not as efficient as always focusing on one thing at a time because of the price tag of context switching, and therefore multitasking is a bad thing.

GTD (Getting Things Done, by David Allen) says: Always pick up tasks depending on context, available time, available energy and (lastly!) priority. This means lots of multitasking.

So which one is right? As in many cases, it depends.

Let’s go through these 4 aspects of GTD one by one and see some pros and cons regarding multitasking:
– Context: If the cost of context switching is high, for example you are a software engineer, and switching to another task means one hour extra work for you, as your development environment needs to be re-configured completely, the size of your WIP limit should be small and you should limit multitasking as much as possible. In other situations, this context switch may cost you only 10 seconds of time (for example briefly writing down somewhere a short summary of the status of your current task), and thus you shouldn’t worry that much about multitasking, but rather focus on the other 3 aspects.
– Available time: If you are a busy person having lots of meetings, and often have only time chunks of 10-20 minutes between meetings, you may work on many small topics, utilizing these short time windows, while some lengthier but more important task would need to wait a bit longer.
– Available energy: For example, if your current task requires intense concentration and intellectual heavy lifting, you may want to consider “taking a break” after lunch, and use food coma time for something that requires less of your brain capacity, like for example administrative tasks, or easier problems to solve.
– Priority: You may lose business opportunities due to completing already started tasks due to applying a predefined WIP limit instead of taking on an even higher priority task (that would represent the given new opportunity, or threat by the way). These lost opportunities or not handled threats are implicitly representing extra cost. Applying GTD you can actually solve this seeming weakness of Lean via keeping a small WIP limit by systematically putting lots of tasks in an „on hold” state in a managed way, but not only blocked ones like in traditional Kanban, but also ones that simply got behind in the priority list!

Even though GTD is more about the personal level, I think these can be applied somehow to the team level as well.

Estimations: Parkinson’s Law vs Hofstadter’s Law

Agile, Lean, Management / ,

Have you heard of these? More likely about the first one than the second.
Here are the definitions:
Parkinson’s Law: „Work expands so as to fill the time available for its completion.”
Hofstadter’s Law: „It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
These two seem to contradict at first, seem to complement each other at the second look, and turn out to say exactly the same thing finally.
1st look:
According to Parkinson’s Law, it seems that work would always take less time than estimated under ideal circumstances, while according to Hofstadter’s Law, work seemingly always takes more time than originally estimated, no matter how big the estimation is. Contradiction.
2nd look:
Parkinson’s Law talks about large bureaucratic organizations, where people’s work is meaningless and thus they get lazy and procrastinating. Hofstadter’s Law is about aggressive and ambitious organizations where everyone is pressed to deliver results fast. Complementing.
3rd look:
According to Parkinson’s Law, preliminary estimations are screwed, as people will cheat them, and even if everything goes well, probably they won’t finish work ahead of time. According to Hofstadter’s Law, preliminary estimations are screwed, as no matter how conservatively you estimate, you’ll keep thinking for a very long time that you are always there, and then in the final moment, everything breaks down and you’ll have lots more left to do. Same thing.

Motivating people – by Machiavelli

Management, Philosophy / ,

Recently I was recommended to read the famous / infamous book of Nicolo Machiavelli: The Prince. He is definitely not a person I would learn ethics from (in the end, he is quite Machiavellian, isn’t he :)). However, throughout reading the book, I’ve found a couple of chapters that contain interesting advice on how to motivate people.

#1: Set inspiring goals (Chapter XXI)

“Nothing makes a prince so much esteemed as great enterprises and setting a fine example. We have in our time Ferdinand of Aragon, the present King of Spain. He can almost be called a new prince, because he has risen, by fame and glory, from being an insignificant king to be the foremost king in Christendom; and if you will consider his deeds you will find them all great and some of them extraordinary. (…) and thus his achievements and designs have always been great, and have kept the minds of his people in suspense and admiration and occupied with the issue of them. And his actions have arisen in such a way, one out of the other, that men have never been given time to work steadily against him.”

#2: Take on big challenges (Chapter XX)

“Without doubt princes become great when they overcome the difficulties and obstacles by which they are confronted, and therefore fortune, especially when she desires to make a new prince great, who has a greater necessity to earn renown than an hereditary one, causes enemies to arise and form designs against him, in order that he may have the opportunity of overcoming them, and by them to mount higher, as by a ladder which his enemies have raised. For this reason many consider that a wise prince, when he has the opportunity, ought with craft to foster some animosity against himself, so that, having crushed it, his renown may rise higher.”

Maybe a little bit too distant analogy to building motivated teams in the 21st century, but still, I found it inspiring.

Here you can read the book online or download it as a free e-book: http://www.gutenberg.org/ebooks/1232

First, change all the rules

Management / ,

After spending my reading-time of more than half a year on all the 5 volumes of Song of Ice and Fire, I decided to read again some serious stuff (not saying that GoT would not be serious in many aspects, but still). The first piece I took was “First, break all the rules” with subtitle “What the world’s greatest managers do differently”.

First of all, the most notable thing about this book is that it dares to call managers managers. In spite of all the BS in corporate world about leaders vs managers, it is clear from this book that this naming question is not so important. Assuming that leaders just need to show the way and then the happy flock will follow completely autonomously and in full harmony is a fairy tale.

What I liked even more is that the authors are suggesting a better way, based on acknowledging diversity of talent and setting clear expectations for each individual, instead of micromanagement and standardization. This is probably where the book title is coming from. I think that rules should not be just broken (because that would mean an ongoing frustration and tension in the management system), but changed for the better as much as possible. I’m not saying there should be no rules, but as few as possible (and here I’m quoting again Henrik Kniberg who calls this Minimal Viable Bureaucracy).

Finally, what I found the best in the book is the emphasis on the importance of recruiting. It’s not possible to create talented and motivated people, but you can only hire such folks, and then do your best to further grow them.

Feature teams and core teams: how to do them best?

Agile, Lean, Management / ,

We are just about to change how we organize our scrum teams. Currently we have component teams, strongly attached to particular technology skills (our focus being client-side mobile library development these are Android, iOS and Windows). However, now having reached (more or less) feature parity across the 3 platforms, and having experiences various drawbacks of this team setup (like unsatisfactory alignment across teams when working on the same feature, or embracing new technologies coming into our scope), we’d like to change to a combination of feature and core teams.

I’ve just read Mattias Skarin’s blog about this topic. It describes the following 4 categories of teams: dynamic feature team, fixed feature team, function team and component team. Even though this is quite a short blog post, it helped me a lot understanding the pros and cons of these various teams.

I see two main challenges with this change:

1. Flow of knowledge regarding technology areas and component code bases. I think a good way to solve this could be something similar to the matrix structure introduced by the engineering organization of Spotify having squads, chapters, guilds and tribes, described by this blog of Henrik Kniberg.

2. Risk of demotivating people in the core team. Most of developers prefer to work on exciting new features compared to bugfixes or relatively small enhancements. The solution may be just the naming of teams. Instead of calling them Core Team and Feature Team 1, Feature Team 2 and so on (in which scenario Core Team may be very easily interpreted as Maintenance Team), let’s give them some codenames, like Red Team, Blue Team, Green Team etc.

Let’s see how well this goes.

A challenge for scientists on Agile tradeoffs

Agile, Lean, Management / , , ,

The other day I attended a meeting where the main topic was Agile process standardization. During the last 9 years of working with Scrum in particular and Agile in general, I’ve been constantly struggling to understand why certain people think such thing as a fully standardized Agile process has right to exist. Of course on the meeting in the end we agreed that this kind of thing should somehow happen, but that was pure diplomacy on my end (why hurt people’s feelings if they are so obsessed).

See Henrik Kniberg’s illustration for example: http://blog.crisp.se/wp-content/uploads/2014/09/Screen-Shot-2014-09-15-at-13.58.35.png

So here’s my question (or you may call it a research challenge for software engineering methodology scientists if you wish): Is there a way to figure out where to draw the slider regarding these dimensions? In a certain situation, should we do detailed estimations or not? Does sprint planning make sense or we should just kanban our tasks? Should we have more of written specifications or we should have more meetings to clarify what needs to be done? Should we scream to management telling that wanting a detailed plan for the next half year and at the same time always interrupt the team is plain schizophrenia, or just let things flow and let our survival instincts solve the problem? Should we let developers just do things their way (often ending up in perfectionist procrastination) or be pushier (and then see the motivation of the kings of today’s world deteriorate in an instant)?

These daily decisions may depend on many things of course, the main ones probably being actual project situation, company culture and individual people being involved. My theory is that always individual people win, but this is just a highly subjective idea.

So all the people who believe measuring this kind of stuff, come and convince me!

Scalable Continuous Improvement Process?

Agile, Lean, Management / ,

I was on a Continuous Improvement related education session the other day, and I experienced something that’s worth to share.

I’m not too much into the philosophical part of Lean and all the Japanese words, Kaizen and all. However, when our trainer spoke about continuous improvement being something that involves small steps of enhancing process and tools in software engineering, I could easily accept it because it made sense.

Then he started to speak about this being an organized process and how to scale this, I started to think. All my experience shows that if Team A wants to make improvements that would change how Team B works, it generates only hot air and politics. However, if there’s some best practice tried out somewhere, why not to share it with others?

So how much bureaucracy is worth having if we want to do bottom-up improvements on a larger scale? How much would this violate team self-organizing? I’m usually in the empowerment camp, while others tend to favor more structure and consistency. Is there a good balance? What is minimal viable bureaucracy here (á la Henrik Kniberg)?

Just questions.

Definition of Done: engineering culture and not enforcing a set of rules

Agile, Lean, Management, Software Engineering / , ,

Yesterday we had a leadership mini-workshop with the key members of my team. A main discussion topic was Definition of Done, both within the “Agile process” section and also in the broader context of “How will we become a great development team”.

Very shortly after we started the usual discussion of “OK, we all know how Done Criteria should look like (like all sorts of desting, documentation, code reviews, quality criteria checks etc.), but how do we enforce that it is happening”, we realized that it is not enforcement that will make it happen. If we push this stuff on developers as an “extra task”, they will push back saying “give me more time for that”. And of course this doesn’t work. There is rarely an extra time and capacity buffer available for this.

What works is to consider this as not a significant extra overhead task, but as natural part of everyday developer behavior, aka culture.

How to achieve this? Our recipe is educating people, providing best practices and positive examples, and remove this from the frontline of the “short term vs long term battle” and make this an almost invisible part of life.