Archive

Archive for August, 2009

Fixing the problem

I’ve already complained here about the lousy online tool that Mittuniversitetet is using for their online courses and the poor quality of their classes but so far I’ve endured it- But I think I’ve had it.

There is some kind of calendar functionality in the system. Not that you can send notifications to another digital calendar, but it at least enables user to log on and you can see what is happening the coming week without looking at all courses. But that requires that all the teachers posts things in the calendar. This week, one of the teachers didn’t. Instead he sent a notification a couple of weeks ago about the exam. But since those cannot be opened afterwards and the calendar was empty, I missed it. He then said that he would open the exam yesterday, but I tested multiple times during the day, without luck.

But today I can see something new on the portal. Since all teachers at least have realized that the tool is not exactly self instructive, they’ve made WebCT browsing mandatory in all classes. But this is not enough, so they’ve also created a specific course in WebCT.

Fixing the problem.

If the problem is that the system does not work for the users, do something about the system. There must be something that works out there on the market. But instead making students waste even more time on their system which they will hopefully never see again after they’ve finished their training is wasting their money and time.

And just to ace that, when I now e-mailed the support, the address given on the web site is not working. How about some lean values on Mittuniversitetet?

So, I think I’m going to skip these classes this autumn and wait for a functioning system or just start reading at another institution. Also, this autumn I’ll be taking a number of 7 steps classes through TUI Nordic. I place my hope in that.

Categories: Agile

The usage of scientific terms in agile

Being interested in the science around for example biologic evolution, one cannot help sometimes seeing patterns in the daily work. When Richard Dawkins discusses the concept of empathy in The Selfish Gene, I can for example see examples in agile values.

But seeing a likeness is not the same as the real thing. I cannot say that what I’m seeing is the same things in The Selfish Gene. It might be the same, but to use a scientific term in good conscience, I cannot.

Jurgen Appelo discusses this in his blog. He’s interested in Complexity Science and is not comfortable with the inclusion of scientific terms in agile everyday speech. When he points at examples, I cannot help agreeing. Being a part of the skeptic movement, I think we should all be weary of pseudo-science and the mal-usage of scientific terms. Just think about Einstein’s theories and how they are now used in the most unscientific manor.

I must confess that I was not aware of the field of complexity science and that these terms are used by that field. And this is of course always a risk, you start using a term unknowing that it’s also a scientific term. But this is not the case in the examples given.

Pseudo-science is never the right path and let us not help in the misuse of scientific terms.

Categories: Agile

Are you productive or just sub optimizing?

I’ve previously posted a number of blog posts where I discuss the dangers of measuring individual productivity. If you believe in The Theory of Constraint, the questioning of this type of measuring becomes natural.

Mendelt Siebanga gives some well put examples of why he also thinks it’s contra productive with measuring individuals but he also discusses how you can increase productivity. A short, well put blog post.

What controls your decisions?

2009/08/25 2 comments

Dan Ariely with his research makes me wonder a lot about the rationality of decisions. To be frank, he’s made me think that there is nothing like a rational decision.

 

Look at these offerings from The Economist. This is an offering Dan found a couple of years ago, and of course the middle options doesn’t seem to be a well thought idea. Now, The Economist made this add by mistake, but it might not be as stupid as one thinks, especially when the offering is made to people, trying to be rational.

image

Dan asked a number of people what they would choose and what he found was that when people were given these options, non chose the middle option, 84% took the last alternative and 16% took the first option.

But here comes the strangeness of the human mind. If a group was presented just the first and the last option, the third option just attracted 32% while 68% chose the first option. You exclude an option that no one wants and that change how people view the offerings differently.

This should have huge implications on usability. I guess we all know that people are not rational, but remembering that when you specify the alternatives of that dialog box is sometimes not easy. Do listen to the whole presentation and you’ll hear the full story. And thanks to Dan Ariely for again pulling away the blindfolds.

Categories: Business, Usability

1715

2009/08/25 1 comment

Is not a year (well, it’s of course a year, but I don’t refer to that here) but a loosely coupled network of Swedish women somehow engaged in software development and who have a special interest in agile and lean values and leadership.

Yesterday evening was spent in their wonderful company. I seldom like groups or networks aiming at a physical criteria, but sometimes those can give you special experiences and questions. By keeping this as a quite small group but with very different perspectives, I hope and believe that we can all learn and teach something.

We’ve now formed a LinkedIn group, where we’ll discuss issues between our meetings, which I hope will be once a month.

Thanks, Ulrika Park, for inviting me, and thanks Sara Manding with Valtech as the evening’s sponsor. And thank to 1715 for a wonderful evening.

Categories: Agile, Leadership, lean

The risk of placing yourself in the shoes of the customer

On my first professional job, I was doing a lot of short consultant gigs and the lack of experience combined with the shortness of some of the assignments sometimes lead to some embarrassing situations where my lack of empathy became evident. With that I don’t mean that I didn’t care about the customers, it was just that I tried to place myself in their shoes and to see how their work could be made more effective. Well, isn’t that being empathic? Not necessarily. 

We’re being learnt that you should treat others like you would yourself like to be treated, that you should place yourself in another person’s situation and this will lead to yourself becoming more empathic to others. Well, this is sort of true but only in situations where your values and person are the same as the other person. Let’s say a robbery: you don’t want to be mugged and no one else would like to be mugged either. But take other things like being able to drive your car faster, one person can think that this would just be great while others see no need and some think the speed is already too high.

Another situation is of course the customer communication. I love companies which enables me to contact them over the web. I booked a service time for my bike yesterday and I just loved that I early a Saturday morning without having to speak to someone could just visit their web site, pick out a free service time and be done with it. My mother on the other hand is the calling type. She wants to talk to someone. So, to be empathic with her needs if I was to improve customer relations, couldn’t simply place myself in her situation; I would have to recognize our differences too. Me in her shoes is not her.

So, when I was out on my short assignments, the mistake I made was thinking myself on their position and trying to figure out what should be improved. And sometimes that was disaster. The first time I really took notice of this was when I visited a person who used Excel to gather information from 30 districts. I wasn’t there about that task, but he brought it up, since he had problems with a formula.

I directly spotted the real problem. The districts formed their own spreadsheets and sent them in to this guy, who copied all these 30 variants into one workbook. To summarize, he had to spot the right value on each spreadsheet. Of course, Excel was not the right tool for this, but that was what they had, so my suggestion was that he would send out a standard workbook to all districts, make them fill out the forms where the same value was in the same cell. Copy this to a common workbook and then use formulas which calculated the same cells (for example E4) on all spreadsheets.

I quickly showed him how this would be done. He was silent. Well, he said, I spend about 3 months every year making these summaries and using this method, it would take ten minutes. I wonder if I can keep my job.

Oops.

I would have hated that tedious and meaningless task, but for him it was his work and he could see no other tasks which he could perform.

Well, of course we shouldn’t accept the wasting of organizations’ money and time and just leave things like this untouched. But I should have shown more empathy towards this guy and recognized that he was proud of his work, a pride I ripped from him in a minute.

Having met a lot of administrative staff, I’ve often seen the same. When a bunch of consultants storm into their office, ready to make everything smoother, they know that they want to get rid of the stuff they do. Seeing themselves doing other tasks might not be that easy. You and me might do that, but don’t take it for granted in others. Don’t place yourself in their shoes. Recognize that you’re not wearing those sneakers; they are.

Their actions might also be strange to you. Many hang on to specific details which they state are mandatory for the process. One common example are ID:s. In many manual processes, people are required to know ID:s by heart. “The object ID is 73645256 A4” and a highly effective member of staff can be the person who knows all these numbers and their history. When a new system is introduced, knowing these numbers can become unnecessary and that changes the knowledge hierarchy of the organization.

The key is knowing that we’re all different and getting to know your customers before barking in on their processes. Spending some time during breaks can give you many hints about the different personalities. Management should also be open with what an improvement in process will mean for the people involved.

Categories: Agile, Business, Leadership

Learning from failure

We all love happy stories, the success. That is; we love to tell those stories. We like to share when we did everything right and when the success came. But what did you learn more from; the success or the failure? When we look at the scientific method, we can see that a failed testing of a theory says more than a non failure. A success means that the theory has not yet been disproven.

When writing Confessions of a serial product owner, downloadable on my site, I tried including my failures as well and it’s almost spooky to hear the words from Scott Bellware at Öredev 2007. Agile is not a silver bullet. Waterfall is not the solution. Is lean the solution? Probably not, but one step at the time is the only way you can walk. The talk is 50 minutes but really starts from scratch if you’re new to agile and lean. Do take the time and thanks TVAgile for sharing the link:

Categories: Agile, Leadership, lean

Informatics teachers stuck in the 70’s

After having taking classes at Swedish Mittuniversitet during the spring and summer, I’ve probably spent more time debating the low understanding of modern software development than learning new stuff. Not exactly what I had in mind when I started taking these classes and from time to time I’ve just thought that I would simply give up. I knew that taking Informatics, which I’ve been working with during my whole career would not bring so much knowledge during the first classes, of course the teachers must take into consideration that students can come directly from high school, but I was totally unprepared when I met teachers who hadn’t even heard of SOA and who thought that agile methodologies are a side track then it comes to managing software projects. Who actually think that a tester should use the original specifications as a key when validating the delivery.

What a tragedy that we train the new students so poorly. One cannot help seeing this as if a teacher used the geography books of 1980. The reality has changed a bit since then and it’s sad that the teachers haven’t bothered to keep themselves updated.

Perhaps it’s the subject of Informatics, when I a couple of years ago took a database class for the same university, I was very pleased with the course and the teacher. It was not like he thought that DB2 was the most modern database system out there. When it comes to these subjects outside the technical sphere, it seems like one enters a time warp. Oh, yes, they’ve heard about the Internet, but I got the feeling that they are very skeptical and think that it’s a some what evil thing since there are no librarians telling them what is “good” information.

This autumn I’m struggling on. I hope that when I now move on the the lesser basic subjects that the teachers are better updated and the classes more challenging. I’m continuing my studies in business process management, I’m taking a class in web informatics, a class in informatics in system development and finally a class in user centered system development. And if the experiences from the previous classes prevails, perhaps I can spark an idea in one of the other students or even one of the teachers.

Categories: Agile

What are you managing, really?

Dave Nicolette shares the story of the manager troubled by the impossibility to track developer productivity.

Isn’t it sad that a well educated person who takes on a leadership role should see his most important task to watch and track others “productivity”? Well, if you think that this measurement is so important; how do you measure if a manager is productive? The number of meetings or charts he presents?

“Yes, Tom is really improving his management productivity, he can now come to a meeting with a 45-slide-presentation instead of the mere 40-slide-presentations he came with last year”

Yes, I know that “you get what you measure” and that you should track improvements. But when it comes to productivity, the tracking of individuals can be misguided. As I’ve discussed in previous posts, optimizing a specific step can often lead to more queues in the system so pushing Bob into writing all that extra code can be bad for the whole process.

Also, in a day and time where empathy becomes more important when it comes to customer and client handling, we are often not satisfied with loads of low quality stuff. We want the thing that breaths inspiration and passion. We get seriously pissed when the supplier market the list of functions if half of them does not work in our system installation.

But the amazing part about the tracking of individual productivity is that the silliness is not exclusive to software development. Think about the first line support. How do you measure their productivity.

“Oh, John has the highest productivity here. He answers and then just hangs up so he can take hundreds of calls every hour.”

“We close our cases within 10 seconds. When we receive them we just state that we won’t fix it and close the case.”

Managers should worry less about how they are going to track their folks and more on how to inspire, coach and develop the people on their teams. If you really want to improve productivity instead of just reading a lot of numbers, here is where your effort should lie.

I’ve perhaps have had bad luck with managers before, having just had one decent one before my current manager. But I can tell the difference when I feel that my manager does what he can to make the thrive and evolve. One of the most important tools we use is direct and open communication. When we can we meet, over lunch, just by the desk and without a computer. Stuff that in the case of Dave’s manager example would see as very unproductive while I think that it’s exactly that viewpoint which makes that guy a very poor manager. Good on you Dave to take the debate!

Categories: Leadership Tags:

Using our kanban board for continuous improvement

Why do you use a kanban board? Why do you use a scrum dashboard? Really? Think about that. And then think again?

Do you track your workload? Do you calculate if you’re going to complete the sprint objectives? Do you use it to divide the work or fetch your tasks?

And why do you manage projects? Is to have something to do? To be able to track progress? Or divide work or just to feel that you’re in control of what is happening?

What ever is your reason if it’s one of the above, I state that this will not help you in the long run. Because this objectives will not improve your work.

This summer I read The Goal and learnt about The Theory Of Constraints. As always, I recommend you reading the complete book, but here is your five minute version.

All processes have constraints. You cannot remove all the constraints in the process, because if one step stops being a constraint, a new step becomes the new constraint.

image

A process with step 2 as the constraint

image

If step 2 becomes more effective, the risk is that the constraint is moved to the next step. So, you cannot just map your process, “remove the constraints” and be happy about your highly effective process. You need to work this continuously.

So, the objective is to constantly improve your process so that the effect of the current constraint is minimized and so that new constraints are identified. But how is that done.

Well, first you identify your current process. All the steps are mapped and then you see where there is some queuing going on. And here comes your Kanban board. Or your scrum board. Or what ever tool you’re using.

Here you follow the value stream of the process and by having a visual tool, you can identify your current constraint.

For example, let’s say that you’re going waterfall. What happens (probably) is that a queue forms at the testing steps. When people finally get to test stuff, a queue of bugs will start to form. And it can form quickly. The step to take then is to try to even the identifying of bugs. Hence you get continuous testing during the process. But then something else starts queuing. And you then use the board to identify that and to improve those steps.

A mistake, according to The Goal, is that we spend too much time optimizing the steps that are not a constraint. But by doing so you just add to the queue. So, if you have a problem with testing not being done, making the software coding faster is not increasing the productivity of the whole process.

I’m really excited to be working with this in TUI Nordic. We’re an organization who is working with lean values and empathic leadership, so this will fit nicely into the culture of the organization. Will it be easy? Hell, no. But a real challenge, yes.