Heynemann – Just another dev

Introduction

Jidoka, also known as “intelligent automation” or “automation with a human touch”, is lean’s way of automating repetitive tasks.

This time we join the INews team as they try to define how far to go with automating or not repetitive processes.

Autonomation

John – Hey guys! How was christmas?
Jane – Pretty good! Yours?
John – Really cool. What about the rest of you?
All – It was great!
Christian – We’ve been talking a lot about lean concepts and I’m not that familiar with lean methodology. Whenever I don’t know something I yearn to learn it. I’ve spent all my free time in the last weeks studying it. One thing that comes over and over is autonomation. That is a kick-ass concept!
Jane – Autonomation?
John – Yeah Jane. Autonomation means automation with intelligence.
Jane – What do you mean “with intelligence”?
John – Well, machines lack intelligence, right? That’s why it’s called artificial intelligence. So automation with intelligence means automation with humans involved. It means automating to become more efficient. It means automating well-known repetitive tasks.
Jane – Oh. I see.
Susan – I think we do that already, right? Our build is automated, for one. Oh! Our tests are automated as well! Hmm… I see your point! We could build and test our app ourselves. We just automated it so we are more effective. We didn’t replace ourselves for a machine. We are using it to help us!
John – Exactly. Still, I think we are not aggressive enough with autonomation. Susan, when we finish stories, what do you do to help us accept them?
Susan – I verify the results versus my mock screens to see that you got the proper sizes, margins, etc.
John – And that’s pretty repetitive, isn’t it? That’s something we could come up with a creative way of automating. Joseph, you perform a lot of exploratory testing as well don’t you?
Joseph – Yes I do, but how can you automate exploratory testing, which is by definition human?
John - Hmm… We can’t automate exploratory testing. What we can do is automate the tests you perform every time. We could come up with some strategy to record the tests you do and automate those. This way, every time you did exploratory testing we would end up with a richer testing suite.
Joseph – I see. Well, I guess we could be more aggressive about autonomation.
Christian – So it seems like a team value, doesn’t it? Automating things to improve our effectiveness.
Joseph – Indeed it does, Christian. Indeed it does.

Conclusion

There’s a big emphasis on not automating things with the intent of replacing humans. The goal of jidoka is to make humans more effective and aid them in detecting problems early and often.

Whenever something can be automated to improve the team’s capacity to respond to change, it should be. The automation should not happen before the actual way of doing things is well-known to the people involved. This is paramount so the automation has the proper goal (as outlined above).

Introduction

The last time we met with the Acme INews team I was telling you guys how they came to the conclusion that if you don’t release it, you lose it. Ok, I’m just kidding, but they all agreed that unreleased code is waste and that it was a value for all of them to diligently work on reducing cycle time variation.

This time around we touch a subject that most companies (well at least some of the ones I know of) don’t like to discuss. Respecting your employees as you expect them to respect you, and allowing them to have fun. Yes, that’s right, FUN! Let’s see what the INews team thinks of that.

Respect

Jane – Hey guys. I wanted to talk to you about something since we first met to do this job.

John – Sure Jane, go ahead. I think we must maintain an open channel for communication at all times if we are to succeed as a team.

Jane – Thanks John. Well, sometimes in my previous projects I got the feeling of being an outsider among developers. I heard comments about how I was being picky and annoying. That made me feel very bad and in those projects I feel like I contributed less than I could because I was afraid of that behavior.

Jake – Jane, that’s a very good thing to discuss. As a client-side developer I heard comments in these areas as well. After discussing with the devs and explaining to them my point of view, things worked out quite alright, though.

Jane – Yeah, it might be so. Even so I still think I shouldn’t have to do that. If we are in a team we trust each other and respect each other’s point of view, right?

John – Absolutely right! There can be no better opinion or prevalent point of view. If we are a multidisciplinary team, we should value each other’s opinions above all and treat each other as we want to be treated in return.

Susan – No offense, guys, but sometimes I feel the designers take our opinion for granted as well.

Jane – Hmm… I see… Can you ellaborate, Susan?

Susan – Sure. Sometimes a designer comes up with an user experience that’s great. It really is. I can see myself loving that experience. It just isn’t realistic given our constraints (might be hardware, network, you name it). Usually I approach the designer and explain that. A lot of times I got a “it’s not my problem” look and had to resort to my boss for help. I would say I didn’t get the same respect I was showing for that professional.

Jane – Sure you didn’t. Well, I guess it does go both ways, doesn’t it?

Joseph – I’m pretty sure we can get along if we just try to always see the other person’s point of view and treat them with the same respect we expect them to show towards us,  don’t you agree?

All – Yep.

I keep getting amazed by how simple they make these things look.

Christian – I’d like to discuss a related topic. When I’m contributing to some project or even coding one of my own, usually I have a purpose to fulfill (I need the feature, someone at work does, or I just find it cool). Even though I have a purpose, if it’s not fun, I won’t do it. No matter how much I force myself to do it, I just won’t.

There will be something else that is a lot more fun to do, or I’ll go read something. I was wondering how can we make sure working in our project is fun. How can we enjoy that feeling of “Great!!! I’m going to work today!” when we wake up?

John – I don’t think there’s one right answer for that. I believe it’s a set of things. A great project makes we want to come work on it (the cool tasks as you said). A great environment where we respect each other does that as well. We already have our XBox 360 and our foosball. How do you guys feel of ‘do whatever you want’ friday?

Christian – What do you mean?

John - Every two or three fridays we’ll get a free day. We can code whatever we want, with whomever we want. We can study, experiment or just play a game together. Anything that improves our project in any way whatsoever.

Susan – That’s a very interesting idea. Can we refactor our own product’s code or implement a feature we’d like to see int he product?

John - Sure. Anything we want.

Jane – Could I use that day for discovery and experimenting with different things?

John - Of course! Anything that you think will help!

Jane – Ok, can’t wait till next Friday!!!

Joseph – I really love that idea. I think we are set in two VERY intertwined values. Might be the same value altogether. Respect and Fun with responsibility. Meaning that we’ll respect each other and have fun together, while delivering business value to ACME. Is that about right?

All – YES!!!

Me - Ok, again with time to spare, and it’s about time to go. Anyone for a settlers game?

Conclusion

Several companies (like Yahoo, JotSpot, Atlassian, Facebook, Google, Atom and Technorati), have already found that by letting your employees self-organize and make their own decisions about the product they are working in pays out big time.

Having a fun environment is not only a bonus to productivity. It is a requirement for creative skilled workers to unlock their full potential. Companies that keep trying to control what their employees are doing (via timesheets, task monitoring or metrics) are in fact killing the motivation that could trigger incredible features to their products.

A product team must be kept in a fun, respectful environment where they can decide what they want to do instead of being bossed around. This way, they’ll be working in the product in their free time, because they want to do it.

There’s a very good video by Dan Pink about what motivates us. Basically it’s authonomy, mastery and purpose. You can learn more by watching the video. I VERY DEEPLY recommend it. It really changed my way of seeing some things.

Introduction

In our last installment, we learned that the INews team decided to never let problems grow and instead solve them as soon as they appear. They also decided on having a formal way of solving problems, so that they (and the rest of the company) may benefit in the future.

This time we accompany them as they discuss a topic that is very near to my heart: Delivery.

Release or not Release, that’s the question

John – Morning all! We had a very productive day yesterday, now didn’t we?

All – Yep.

Susan – I’m sooooo sleepy, John! (*chuckles*) Yesterday I went home thinking about some values that I hold dear. I’m not sure this is the time to discuss it, but I really enjoy delivering business value. I’m filled with joy when I realize that my work is helping our coworkers in being more productive RIGHT NOW. How do you guys stand on this?

John – Well, when you study Lean Manufacturing, you learn all about delivering, since they consider anything that is not being used by a customer or adding value to a product to be waste. So, if you are a factory worker, your sole purpose is to drive the product as fast as possible to a client. Please note that as fast as possible takes into account every single quality factor that the customer expects.

Christian – I have a lot of experience in delivering, but we call that releases in my projects. I release as often as I can so I can gather feedback from the community. It is also a very good idea to release as much as you can to minimize the amount of work that goes into a release.

Jake – I don’t have much experience in this area, but something tells me that releasing often makes a lot of sense. I was just wondering how the big guys do it: JQuery, Django, Apache and other projects like that. How do they release?

Christian – I’m not sure how they do their releases, but I love apache’s concept of a release: “Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released.” [1]

John - Yeah, couldn’t agree more. You should release as much as makes sense. Unreleased code sitting in our laptops does no good to our clients.

Jane - Well, when I design a user experience for a product, I have to think a little ahead about how our users are going to interact with it. Imagining their experience is in no way a substitute for learning how they are actually using it, so I too consider it to be crucial to have customers using our product as fast as we can, even if we have to cut a little bit on the feature side.

Joseph - Funny thing, I just purchased Continuous Delivery, a book that was just released (no pun intended). This is one of my favorite subjects. I do believe in continuous delivery. As soon as we mark features as complete, we have them in production. Lean Manufacturing introduces a measure called cycle time, which means the total time between a customer requesting something and the customer getting to use it. What I understand we just agreed, is that we will work diligently to reduce our cycle time as much as we can.

John - That sounds about right!

Me – Once more with time to spare! Let’s play some foosball.

Conclusion

Sometimes we are working in something really cool in our projects. Sometimes we are just fixing stuff. The point here is not what we are doing. It’s who’s benefiting from it.

If you are building software I assume that someone is going to use what you are building. If that’s the case, until that customer starts benefiting, your code is waste.

Cycle time is a very interesting measure, in that it measures your turn-around time to new features, as much as your responsiveness to issues that you or your customers find in the software.

From Wikipedia:

Cycle time variation is a proven metric and philosophy for continuous improvement with the aim of driving down the deviations in the time it takes to produce successive units on a production line.^[1] It supports organizations’ application of lean manufacturing or lean production by eliminating wasteful expenditure of resources. It is distinguished from some of the more common applications by its different focus of creating a structure for progressively reducing the sources of internal variation that leads to workarounds and disruption causing these wastes to accumulate in the first place. Although it is often used as an indicator of lean progress, its use promotes a structured approach to reducing disruption that impacts efficiency, quality, and value.^[2]

In my humble opinion, the best thing about cycle time is that it is a TEAM metric and not an individual one. That means that if the team collaborate to improve work and reduce waste everyone benefits from it.