Taking care of people and business

It is for a good reason that the agile movement should be based on the agile manifesto – I think it’s a sign of strength to be able to state what basic principles you base your work on. But why do I find this so important?

Independent of if your process is packed with rules, artifacts or roles or if these things are kept to a minimum and independent if you use agile or waterfall, situation arise when the process and the rules make more harm than good. If you then have shared values, these can guide you so that the rules don’t become more important than the outcome. “This is by the book” is in my world a sorry excuse for not having good arguments for why you act as you do. Even if something is in a book, you should not hide behind that. Of course there are corporate rules which you must decide to follow as being part of an organization, but values can be helpful in stopping people using these rules for their own purposes, that being laziness, fright, power lust, uninterested, uncertainty or what ever is behind hiding behind books and regulations.

It is my opinion that processes and rules should help us reached the highest sustainable productivity in order to reach corporate objectives. In order to do so we need to take good care of our business and very good care of the people which are a part of this business: customers, partners, employees, etc. Not that we should be afraid of hurting their feelings and therefore tiptoeing around problems (this is in my opinion quite the opposite of what you should do) but every time you hit someone with “this is by the book” they will not reach the highest sustainable pace. They still don’t understand. There is also a good chance you kill their spark. Therefore People over Processes. In the agile movement we care about the people. That is why I agree that we should stop using the word resources and this is why we have loads of habits in the agile processes. But they are not there because they are in a book, they are there for a reason.

This is perhaps also why I now here so many complaints about methods like scrum. I hear more and more getting the feeling that many scrum implementations have lost touch with People over Processes and are holding on to habits which are not the best for the long term or the short term productivity and seem to be there just because they are in a book.

But I’m not working for checking off that we’ve followed all the rules in a book. I work for making holiday dreams coming true. What do you do?

New project, new examples

As of a couple of days ago, I’m splitting my time between two projects. As it happens it’s also on two different locations here in Stockholm so I’m happy that we have a warm autumn here in Stockholm so I can ride my bike between the projects, but what is really fun is that we’re using Specification By Example in both projects.

One major difference between my work will though be that I’m a core team member in my “old” project, while I will be an outsider/stakeholder in the new project. I’m supporting our product owner and writing examples but not be an active team member. This will very interesting to experience in combination with Specification By Examples – does example writing business people have to be part of the team?

This means that I’m that fortunate that while learning this I get lessons in two rather different projects and from two rather different styles of implementation of the examples.

Today, I had the first specification session with the new project and we started of discussing what we want to catch in the examples in the project. We then started writing examples, both some that are included in the scope of the original user stories but also the framework for examples to be implemented in later stories. Tomorrow we will test the examples on the team. This will be really interesting to see and hear.

Another difference between the projects is that we will be using a more conservative form of scrum in this project which is also very interesting when comparing with the other project where we have used something more of an almost post agile process with few fixed artifacts and more a continious adaptation of our process in order to improve productivity.