Estimates or #noestimates

Everyone working is Software industry have been involved in estimates in a way or another. Most of the people have known for ages that the one thing that's sure for estimates is that those are wrong. More complex the software or organization creating the software, more difficult it has been to estimate how long creating software takes.

There's been buzzing around for some time the #noestimates movement. The basics of it, as I understand, is that software teams should get rid of making estimates, since those do more harm than good. But I think there goes so much discussion under #noestimates, that I'm not fully sure what all it contains.

I've seen estimates to do lot of harm in many organizations. Estimates have caused poor quality, unhappy people and lot of unnecessary waste on creating those and reacting to those. But then on the other hand, I couldn't see organizations to live without any estimates on software.

Value of estimating versus the time used to it

Value of the estimates versus the time used on creating the estimates is one of the key questions on estimating. Too often estimating takes lot of time. People use hours or easily even days to figure out how much time creating some software takes.

I guess it's not valuable to discuss too much about what's wrong with estimating. People are known to be terrible at estimating. One excellent source to understand more is Nobel prize winner Daniel Kahneman's Thinking, Fast and Slow which introduces at least WYSIATI, anchoring effect and lots of other reasons we can't estimate. So I'm not going to use more time on arguing about the subject, but use is as a given fact that people are bad at estimating.

So what is the reason estimates still exist. Why estimates are still done, even though those are always thought to be wrong. I believe estimating goes to the same category as planning. As Eisenhower said: "Plans are worthless, but planning is everything", there's something similar with estimates. Estimates as such are not accurate, but the journey is valuable and some figures are always needed.

Sometimes the time spent doing the estimates doesn't match the value that estimates can give. Estimates should be used as a tools for decision making. Most often the decision is that should something be tried to do or not. The decision should be about the start, not about the completion. That's what Agile and iterative thinking should help on, there should come multiple decision making points and clarifications about the completion when knowledge increases during the development.

Companies can't live without estimates

Liked it or not, companies can't live without estimates. Most of the companies have limited resources in developing software (and everything else too). Those few who currently seem to have unlimited resources, still need to serve their customers quite often to keep their positions.

In real life, there are customer commitments and internal commitments that need to be handled somehow. Most of these are based on estimates, things that are most probably not accurate. Still those don't change the fact that sometimes these commitments need to be given. Think about yourself, would you be willing to purchase a house building project, if your contractor would say that we don't really know how much it will cost, when it will be ready and what it will contain. Of course you want to get an estimate, or even a fixed price with fixed timeline and features.

Many companies actually are in estimating business. They estimate the costs of development, they estimate their sales, they estimate the timelines and then take known risk with price and profit margin. This is how most of businesses still work. The luxury of making fixed profit is with fixed hour rate businesses. So basically some of consultants, lawyers and couple of others. There the risk is in not getting clients and not in making bad estimates.

Other than actual businesses relying on estimates, many companies have internal dependencies to SW development estimates. Product marketing for example, can't wait for product to be finished before marketing activities can start. They might need easily few months head start to get all the activities ready when product would be ready to ship. There easily are tens of these dependencies inside companies to the software team estimates: sales , marketing, documentation, hardware creation, operations, training, partners and so many others.

Software estimates, as much as software teams hate those, and as much those are wrong are mandatory part of all businesses. Those of you who still hesitate, think about Lean value stream map. For customer, software is just a small part of product. Even a plain software product. I can't even invent a software that wouldn't need other activities to go parallel to software creation to shorten the full cycle.

What's the solution then

Estimates are problematic. Sometimes estimates cause waste, sometimes lack of estimates cause waste. When sales uses SW development estimates as promises, those can create business, but at the same time those might cause quality issues, stress and unhappy people. So what could be done to estimating, when to do estimates and how.

I can reveal already now, that I'm not a believer of black or white solutions, so I don't think there is a one solution for all. But here's couple of thoughts how situation with estimating could be improved.

Estimated targets and predictions

One possible solution is to go towards having targets from early estimates and then predictions separately. At least when estimates are not in the team level, but in the project or feature level, it would be beneficial to have a target and then constantly update the predictions based on progress. Both of these figures should be always visible and that would give to everyone else idea what is the real situation.

In this approach there are many potential problems also. People tend to keep the first estimated targets as the goals and then predictions as a follow-up of the situation. This might give the feeling of failure, when the first estimates will most often be wrong. Still this approach should give everyone the idea, that decisions are made with something that will most probably be wrong.

Software aided and fact based estimating

As discussed, people are terrible at estimating. In a way it's easy to say that computers can't be worse. Saying this, I've never seen a good software that could do this properly. There are quite many variables that needs to be taken in to account to have a proper estimate. Still I believe that it would be possible to create framework that would give rough estimates of projects or features.

This framework should benefit from the historical data that has been stored to many software tools that has been used in the organizations. As an input, the framework would need to get software components that require changes. Then based on throughput times in past and historical progress of projects estimating software could give an idea how long something will take. Even thought these estimates would be quite rough ones, still it would give valuable data for human made estimating. And I believe it still would be closer to the truth than many other estimates. As said, unfortunately I haven't seen system like this yet in place. I would be surprised if there wouldn't be any software projects ongoing in this field. I just haven't bumped in to those yet.

It's ready when it's ready

There are few companies who have been good on preventing the harm what bad estimates have on markets. Apple is the prime example of this. I'm hundred percent sure, that even the guys in apple are bad at estimating. They concentrate on the product quality, so they can't guess when they are ready. They have taken the approach on telling when things are ready when those are ready. In Apple case it works for their benefit, but many other companies need to be able to have some timelines beforehand.

Still the approach it's ready when it's ready has something to learn from. It starts with understanding, that estimating software project length is difficult. When this is realized, then companies should build their activities based on this. Sales shouldn't be selling exact dates too early, handovers and dependencies between different teams should be minimized and people shouldn't be rewarded or punished because the estimates they have given.

Software, even the minimum viable product, won't be ready before it's ready. There isn't any amount of estimating activities before hand which can tell for sure when the ready will be. Activities in companies need to be able to react to each others timelines and not work with fixed timelines.

Summary

Estimating is a key aspect of business in software business (and basically in any other business). There are too many aspects and ideas to improve estimating for a one blog post. Some people believe in time boxed development, others think Minimum Viable Product will help and some believe tools will be the thing that will fix the issues. I don't believe there is one solution to fix it. I see the key thing to be that people start to understand that estimating is really hard and people are bad at it. Most businesses need estimates and can't live without those.

As a feedback to many of Agile and Lean discussion ongoing in different forums, I have to say that too many people forget the business behind software. It's so easy to talk about no estimates thinking, Agile practices or Lean values without understanding the effects of it to the businesses. Software is a key part of many businesses, but it won't make money without the other activities in the companies.

Everyone involved in the estimating processes should acknowledge what is the decision estimates are used for. Minimum Viable Estimate could be a good guidance for everyone. What is the minimum level of estimate we need to know in order to make the decision in hand. And as reminder to everyone, estimates don't get better with estimating, those get better with implementing.


Written by +Henri Hämäläinen

Agile State of Mind has been lost in the journey towards Agile

First statement in Agile manifesto is “Individuals and interactions over processes and tools”. When people talk about Agile SW development, much of the talk is about processes and tools. If they are not talking about Scrum or Kanban, then it’s about code reviews or Test Driven Development. Too often the basis for all of this is forgotten.

I think there has been a clear vision of all of this. Back in the years that this movement started, Agile Manifesto was written with careful thinking. Somehow the message got lost in the way. Currently there are so many different methodologies and processes, that have been introduced under the Agile umbrella, that what really is Agile is unclear.

In team sports, there’s always ongoing trends on playing tactics. In football, at the time Barcelona and Spain was dominating, many teams wanted to play like them. What often went wrong was that teams and especially the players didn’t seem to understand the ideology behind the tactics well enough. They were just mimicking the ways others play, but didn’t really understood the reasoning of why to play like that. This lead to the problem, that in a second that there came a problem which didn’t have ready made solution, players didn’t know how to act. This was all because they didn’t understand the reasoning why they had done some of the things in the field like they had.

I believe this same is happening with Agile. People are happy and productive when everything is going like the books have told. At the moment there comes something unexpected, people don’t understand the logic of making choices. Making choices in SW development is never easy. For example in Backlog creation, there needs to be done many guesses and estimates on items when prioritising it. Creating user story items or what ever we call them, is never exact science and always needs judgement from the person in charge.

Focus in many organizations should go towards how to successfully create SW products with Agile State of Mind. That’s at the end what SW development is all about, creating SW for customers. Being Agile in SW development means, that focus should be on creating more value to the customer with improved ways of working. Not just to improve the ways of working.

Written by +Henri Hämäläinen

Book Review: Management 3.0 by Jurgen Appelo

Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo was one of the books that I've planned to read for a long time. The positive thing about reading it now and not earlier, is that I was much more ready to understand the book than I was few years ago.

Management 3.0 is an excellent book. Even though the name might promise a one more management model to learn, Jurgen Appelo tells that there isn't a model that would suit all. To be more precise, Jurgen tells that all models have their flaws. He does say that models are important, but we need to remember that all companies, products, people and environment are different in every case.

Jurgen does give his view on what is important in Management in the future. His model has six major themes, which start from energizing people and go all the way to improve everything. He goes all his themes through with very extensive walk-through of underlying knowledge on each of the areas. He explains things thoroughly, but still interestingly.

I really liked the book. It was excellent reading and widened my view of the importance of people in companies. It does discuss about many of the same issues that other Agile books, but it does add lot of new ideas to the discussion.

I recommend this book to managers in product development companies and others who are interested on how the whole companies should be organized. It's a great book and I promise you won't be disappointed.

Written by +Henri Hämäläinen

Book Review: Agile Software Requirements

I did read this book a while ago, but I somehow had forgotten to review it. I recently took it from my bookshelf to check few things and decided to write a review about it.

First of all, I think the book title sucks. Dean Leffingwell's book is named Agile Software Requirements, but it is all about the Enterprise Agile model called Scaled Agile Framework (a.k.a. SAFe). I don't understand why that couldn't have been the title of the book also.

I have hands on experience about SAFe model, when it was invented (at least partly) at Nokia. I was heavily involved in taking it in to use in Multimedia area. I don't want to talk too much about SAFe model this time, I try to concentrate more on the book side. I have to say I'm not a huge fan of the SAFe model, but it does make many good points and definitely adds value to certain kind of organizations.

The book as such was a disappointment. It does have some good insights in many of the different chapters, but it is way too long. Everything about the book could have been said in around 200 pages. There is lot of repeating the same basic things in many different chapters.

Maybe it's just me getting bored, but I'm not sure if all Agile books need to repeat the how Scrum works and all the other basic things. I guess we could get over that part on the future books. I do realize those are easy to skip, but I don't easily skip chapters, because authors have wanted those to be there.

What I liked about the book was that it shows that software development affects to so many different parts of organization. There needs to be well planned mechanism to have proper amount of guidance to write the actual code.

For those who have no idea how to scale Agile software development to larger scale organizations, this might be a good book to read. It gives one view how scaling can be done, but it is too strict for my taste. I don't believe there to be one size fits all solution. I think I've heard Leffingwell to say the same thing, but the book forgets to tell about the other possibilities.

I'm not sure if I would actually recommend the book to anyone. Scaled Agile Framework is definitely worth of checking at, but you can get almost the same level understanding from the SAFe webpage. It didn't raise to be any of my favorite Agile books.

Written by +Henri Hämäläinen

Separate Testing is Waste

Thinking very Lean, testing is waste. Testing takes time and doesn't bring any value to the customer. Most of the it only provides information, that product works as expected. Only time testing brings value to the customer is when errors are found.

Testing is seen as an important activity. There is lot of focus on improving testing and the coverage of testing. More and more people are working testing products and creating test cases. These activities, do improve the product quality a bit, but it isn't really a way forward.

Testing is a wide subject, and I'm talking especially on the cases were testing and product creation are seen as separate activities. There might even be separate test teams and separate product teams. Product teams do test to some extend, but the main responsibilities are given to test team. This is the big problem of testing. Separate testing should only be about knowing the risk level of releasing, not about increasing the product quality.

The aim should be to decrease the amount of testing and increasing the the product quality during the product creation. In the long run, the thing that matters is the product creation quality, not testing quality. Of course some of the product creation quality comes from testing, but this is not separate testing, but assuring the quality while creating something.

I don't believe any organization can get rid of testing. Some amount of testing is always necessary to know the risk level of releasing. Amount of testing needed should be analyzed thinking the costs and effects of fault in product release. In some businesses fault could mean bankrupt, in others, few annoyed customers. This analysis should tell the amount and scope of needed separate testing.

Testing and product creation should work together to ensure quality of the product. Organizations need to learn to build good quality products from the start. Every error should be analyzed and corrective actions should be made. Unfortunately this is utopia in most of the companies. Errors found in testing are seen as normal way to ensure quality. In the long run this will start hurting organizations and cause more and more errors.

The only way forward, is for management to start taking errors seriously. Especially having an eye on why the errors have been introduced in the first place, not why the errors were not caught in testing. Blame is often put to testing, even though it's an activity that shouldn't be done separately at all.

Written by +Henri Hämäläinen

Book Review - Scaling Lean & Agile Development

I haven't lately read that many books on Agile and software development, since I have felt that I learn more about software development reading about other subject than software development. Also some of the books have been quite boring, but I wanted give Craig Larmans and Bas Voddes book a change based on good reviews I had seen.

Too often books about Agile or Lean say mainly the same things that all other books are saying. Scaling Lean & Agile Development was a fresh exception. Although it did explain many of the basic things, but it did those with easy and compact form, so it wasn't disturbing.

Book goes thoroughly through many different aspects of Agile development in larger scale. It does concentrate on Scrum in it's name, but it does look the things from really from organizational perspective. It doesn't only look from certain layers, but it tries to cover many different aspect. It actually tells about the agile transformation and thinking tools also to get into scaled agile development.

It is easy and fun to read, but it does require background knowledge of agile development, scrum and lean to  get most benefits from it. So it isn't the first book to read about agile, but somehow I feel it never is the first book.

I enjoyed it a lot and highly recommend it to anyone who are in organization which have more than one development team doing software development.

Written by +Henri Hämäläinen

Book Review: Implementing Lean Software Development

For about half a year, there was laying on my table the book Implementing Lean Software Development by Mary and Tom Poppendieck. I was working mainly as a Product Manager for a year, so software development issues were not the number one thing on my mind. Now I have been for four months in a really
interesting project to improve software development of a company. I've been really excited about it and for that reason wanted to remind myself on excellent insights I knew Poppendieck's have.

I've read Poppendieck book's before and followed their teachings for some time already. This book had slipped my radar for some reason and I'm actually glad it had. It was really nice to go through thoughts from basics of Lean and Agile software development, without still wasting many pages on those. This book excellently reminds on the basics, but still give valuable information for the more experienced ones.

Book is full of excellent examples starting from the 70's and 80's, but coming back to the latest years. It explains all the things shortly, but understandably. It is excellent source for information and ideas for further information seeking.

What I've always liked about their thinking, is that they don't ever seem to get in to the hype's. They understand that hype's are hype's and Lean and Agile are something more sustainable. Getting better in software development is never about some specific ways of working. It is always about improvement and doing things better than previously.

I don't recommend it to be the first book about Lean or Agile software development. It gives something for everyone, but it is more valuable when one has got more experience to map the information against.

It was an excellent book and I enjoyed it enormously.

Written by +Henri Hämäläinen

Book review - Lean Software Development by Mary & Tom Poppendieck

This was one of the books I've planned to read from the days I started with Agile SW development projects. This was the book many said I should read about agile. I'm almost embarrassed that it took so long for me to start with this book. Now I've finally read it. Was it worth it? Definitely.

What I love about the book Lean Software Development by Mary and Tom Poppendieck is that even it's subtitle is Agile Toolkit, it isn't a such a toolkit that offers ready made solutions. I've never believed this one size fits all thinking which is sometimes pushed with Scrum and Kanban literature and this is refreshing exception to that thinking. This one offers explanations why things tend to go in some ways and what are the user or organizational problems these tools are trying to solve.

I'm actually pleased that I didn't read this when I was a fresh starter with Agile and Lean. I somehow feel the book would have been bit too much on that time. This book really encourages to see the whole and understand the underlying causalities between different parts of SW development. For that reason it was good that I had experience on many different levels and layers of Agile and Lean SW development to be able to reflect the lessons in the book to real life situations.

Book has lot of examples, most of them which really adds value to the book. Examples are often the best way to explain how the theory actually works in practice. That was exactly the way this book used examples. Some of the examples even felt really familiar to me and I noticed being in a similar situations which were described in these examples. That helped me to map these things better to real life.

I would recommend this book to all of you who want to understand the bigger picture with Agile and Lean SW development. This is the book that really sets the grounds to understand what this all actually is about. It gives more flesh around the bones for Agile and Lean. Those who need to see the whole before really understanding the details, this is the book for you.

Written by +Henri Hämäläinen

What can we learn from UX in Grocery store

Have you ever thought user experience on grocery store. They have been thinking it for much longer than anyone on IT. Here’s my observations.

Often first ones when you come in are the fruits and vegetables. I think those have a couple of meanings. First those most often look nice and give a fresh look to the store. Second those actually takes most of the time in store, so having those first make store look popular, since there is always people there. Third, most of the people will always get something from that section, so it is convenient to have it first, to minimize the trouble from everyone.

Shelves in the store are designed so that in the level of the eye and hand there are the most popular and most used items. In the top and bottom shelves are niche products, which users of those will find even from non optimal places.

Many stores also use the trick on placing products, which have a best before date coming sooner, on the right side of line of products. There are more right-handed people, so those products will get sold before the date from the right side.

Then thinking about cash desk. There are products which are often bought impulsively, like candies and soft drinks. Also close to cash desks there are products which are easy to steal, so cash personnel can try to take an eye on those ones.

In addition, there’s lot of stuff ongoing in the background making sure there are things to sell and those are fresh. Logistics and everything is meant to be silent and unnoticed, still having one of the most important parts of user experience. If there’s nothing to sell in grocery store, user experience is always terrible.

If you compare this to any software, it’s not that different. You want your customers to think this is fresh and easy to use. You want to look popular. You want your content to be there. You want people to exploit some new stuff also on the way. UX in grocery store and SW are not that different. And I actually think no user experience is that different from another.

This was originally posted 6.12.2010 at lostinux.wordpress.com. I've closed that blog of mine and I'm re-posting some of the most popular and best posts from there to here.
Written by +Henri Hämäläinen

Self organizing teams - is it the best practise or a myth?

In many management literature and methodologies self organizing teams have been thought to be the best ones. This is one thing I've never really understood. I have a background from many sports and I don't know a single team in the history of sports which would have been successful as self organizing one. Also I haven't met many self organizing teams which would work really well. Is the whole thing just beautiful thought or is the concept of self organizing team misunderstood? Or is it just me?

How I see self organizing teams are understood and also how I've understood it, is that self organizing team is a team which is independent, can solve problems on their own, are capable of best solutions due to being all-inclusive (having the necessary skills) and also are able to divide their work on most effective way using the intelligence of the group (self led). This is the idea what this writing is based on.

Many Agile SW development frameworks proposes self organizing teams as the basis for the whole framework to work. Argumentation is that teams are much motivated when they have empowerment to decide about their work. Also they commit and keep their promises much better because they have the possibility to make the decisions about their own work. This all makes sense, almost everyone likes when they get to choose how they do things and what they commit to.

At this point I always start to think on sports. Why there's so many coaches and people around the teams to help them do better? Doesn't the guys in the field know the best how to handle different situations? Doesn't experiences teams know how to adapt to changes in the field themselves? Why sport teams are not self organizing?

Some of the best teams in the world are really capable to handle many situations themselves. And yes the teams are in the field themselves and reacting themselves. But what is different is that they have been prepared to handle many of the situations up front. They have been learning different ways to approach the problem. They have in their minds playbook full of way's to tackle the problem they come in to. They have been preparing, they are most often ready for the challenge ahead. Even for surprising things, they may have common rules to follow to mitigate the potential danger. All this is done with the help outside of the team in the field.

It's easy to argue that sports are different than work life teams. Sport teams train much more and actually "work" much less, and on the other hand work teams "work" most of the time and almost never practice. As said sport teams have much more support personnel and work teams have much less. Also with sport teams there's more strict rules to follow that with work teams. But are those still such a different ones. Team is a team whatever the game is or whatever the purpose is.

Now coming back to the self directing team thinking. Does team really need to be independent? It would make sense that teams would have the best possible knowledge to tackle any given task. Most often there's someone out of the team who has some more insights and ideas on ways to tackle the task. Team can never be complete, there's always some competence out of the team that would be beneficial for the team. Always.

What about the self organizing/self led teams then, is self organizing the best way to organize? Is getting the job done the same thing as doing a good job? Sure all teams can self organize, always they do come up with some solution how to divide the work and so forth. Many experienced teams might even do a really good job, but many teams unfortunately don't. Often the result is not leading to learning and using the best people to work on most important issues. Self organizing tends to please everyone in the team and on that way might not be the best thing for the team or the product they are working on.

The main catch with self organizing team is the motivating aspect. Possibility to control your own work and doings is motivating. Doing what you desire leads to the best results in long run. Still true motivation is self centric, it evolves from personal desire's and ambitions and in this case requires that the thing team does is motivating as such. Then there's an extra motivation coming from the possibility to affect more on the things you should be doing.

I think concept of self organizing teams might have been misunderstood a bit. True value of the team comes from it's capability to be more valuable with co-operation than it's individuals would be themselves. Team can be always detected to be a team, but the boundaries of the team aren't always that clear. Is a soccer team only the guys in the field? What about the guys in the bench? What about the guys participating in training? Or all the supporting people, are they part of the team? What actually matters is the result, not the team composition. Teams in work life could also be more open and loosen the boundaries of the team to be able to respond and get help from outside always when needed.

If you think sports teams there's always people to help. Coaches help building the competences all the time, during practices, games and all the time between. Also other support personnel react when there is need to get help for someone. All of these share the common goal and work towards the same target, still only part of these do actual visible work. Maybe this would be a place for work life organizations to learn. Maybe there could be much more coaches and supporting personnel to help, advice, boost and even watch over the team, to make sure team performs and learns the optimal way.

Sure there's many questions that how would this work out in real work life, but I encourage you to look outside the box and really try to reason why the teams need to be self organizing and self led. Is it really the best alternative out there. Could there be some other alternatives which would maybe take some of the freedom away, but would actually boost the effectiveness on the other hand.

Written by +Henri Hämäläinen

Team dynamics - Can group of specialists be a good team?

Yesterday in Agile gathering we discussed about how teams work and how to get teams work more like a team. There was lot of talk about specialists and generalists and how to spread the information of specialists to other team members to make team more successful.

Afterwards I started to think sports. All sports, for example soccer, american football, basketball, you name it are full of specialists. Best teams have most suitable specialists working together to make even more value out of each other as a team. Team member knows each others strengths and use those to beat the opponents.

 Sport teams are bit different than the work ones. There's always games and opponents where teams are weighted. Most of the time is spent practicing. Teams have team practices and individuals practice their specialties. Also there's a playbook to follow. It gives guidelines for problems that arrive rapidly in the field to make decisions which the whole team knows about. Still there's always room for excellent individuals to make their own decisions to make a difference.

Does teams work best if everyone is equal and generalist? Maybe not. Some people are always better than others in some tasks. They should be allowed to come even better on their area to make the whole team better. Main task for line manager or scrum master or whomever is watching the team is to make sure that there's a possibility to learn. Everyone should have the possibility to learn from the more experienced ones. There will always be situations when these less experienced ones need to take the responsibility and tackle the situation.

I see playbooks as an interesting idea. Maybe teams in work life could also have a playbook. That would give guidance to tackle most commonly faced problems. It would give guidelines how to start looking for solutions, but it still would leave room for individuals to make their own decisions. These could be used in discussion, retrospectives and learning's. Maybe those can't be taken directly from sports, but the idea feels interesting to me.

Self directing teams are often said to be the most successful ones. Still in sports there no fully self directing teams. In some sports, like soccer and basketball, teams are more on the self directing side when they are on the field. Then in some others like american football, there's more guidance from the coaches all the time. Maybe this self directing thing is more of a motivational issue than performance issue. Worth to keep in mind still.

I know sports is not the same as work life. There's so many differences. Maybe still, there's something to learn in work life also.  

Written by +Henri Hämäläinen

One subject blogs comes soon quite boring

I wouldn't like to keep many blogs. I already have two, this one and then one stream of funny stuff in Posterous. Still many guide that you should try to blog about one narrow subject, so that people would know what to expect. That would make them follow you. In a longer term, I think it's bit other way around.

I've been following for example Agile blogs for some time. One after another those start to become more borer and borer. Agile is still quite narrow subject where renewal of different methods and thoughts takes time. No one can really write interesting new views on agile 100 times a year.

I think more and more, people are finding writings by recommendation or social stream. So people are not following exact blogs only, but writings that are detected by someone else and are visible in websites, twitter and FB streams. This also supports my approach of wider scope.

Why I actually started to think on this, was that I thought that how much I should mix things from personal interest and professional interest on this blog. For example, I'm not that an agilist, that I would without my job, really follow that closely what's happening with Agile. But then, I am following some of the tech stuff just for personal interest. Same goes with many other things. Some stuff I follow and know from business and some from personal life.

I actually convinced myself, that I'm going to continue blogging on misc subjects, since that so much more fun. You can write on anything that comes to you mind. If people don't like, then they don't read it. Skipping content is easier than ever. And there's so much always happening in the world and life, that it would be shame to try to keep with one subject. Hope you agree and read me some other time also.

I revisited my thoughts 3.12.2010. Here's a post for that one: My thoughts on one subject blogs revisited.