In the middle

I’m currently in the middle of a small (2 months) but important project. I wouldn’t say that we’re following a specific software development method but instead we try working after a few principles, which are maturing as we work.

1. Clear decision maker.
The developers know that there are so many business people involved but there is only one decision maker.

2. We talk every day.
At least once a day we talk. That does not mean a formal meeting. Sometimes it’s many small gatherings, sometimes it’s a formal meeting in a conference room, sometimes I call the developers one at the time. But we talk every day.

3. Status updates to key business people at least once a week.
This is not necessarily the managers but all who are affected by the project in their daily work. They are always informed on current status and we can repeat information on what is being delivered.

4. We don’t do stuff which takes long time.
We’re on a tight schedule so every hour count. If someone gets stuck, he need to address that at once.

5. We only do stuff which we have a good feeling about.
Since we are on a tight schedule, we must be careful not to do things in a bad manor. This does not mean that all solutions are the most refined. They are supposed to be the best ones, given the circumstances, but if someone feels uncomfortabld with a solution, we should avoid it.

6. At least one developer on business meetings.
We have many and short meetings with the business and include the developers. They are better at explaining what they are doing than anyone else and need details on requirements than anyone else.

7. Sleep on it.
If something seems unmanageable, we try not to decide directly but instead sleep on it. Many problems have just handled themselves.

8. Take the time to explain.
When someone has an issue with something, we try not address this in big meetings. Instead we take the time with more one to one meetings. Here is empathic listening crucial. But also clarity about what is important from a wider perspective.

9. Build on trust.
The basic principle is that we trust each other, that we act as someone to be trusted and that we build our solutions on that. This does not mean that we don’t follow security regulations but rather that all solutions should not be based on the assumption that co workers cannot be trusted. Instead we protect what is very important and explain our solutions in order to clarify how things work. If it turns out that someone is breaking the trust, this is a bigger problem.

10. Have fun.
We try to spend as much time on things that are fun to do. Creating functionality which help our customers is fun. Creating functionality which helps our business is fun. Clearing out misunderstandings is fun. Delivering a release which we can be proud of is fun.

As I mentioned, I wouldn’t say that we use an agile method but instead we work with an agile heart.

A sense of urgency

John Kotter stresses the importance of creating a sense of emergency. Working with the 7 habits program, this might seem like a really bad idea.

Urgency according to 7 habits

The 7 habits program divides tasks into four types:

I Urgent and Important – the crisis, stuff which is important and must be done “now”

II Not urgent but important – the strategic work, important tasks which must not be done at once, but if not taken care of is in the risk of becoming urgent.

III Urgent but not important – tasks which you don’t really see the point with but is urgent. This is mostly tasks which others want you to do.

IV Not important and Not urgent – these are the tasks which brings no value and which might bring a sense of wasting your time and guilt for not making use of your time.

The 7 habits program wants you to spend more time in sector II, since this avoids the I:s and creates a productive work profile. If you spend too much time in I, you will probably feel wasted and the rest of the time is spent in sector IV, since you don’t have the energy for anything else.

Urgency according to Kotter

When people think something is important, they can work harder and be more productive. By creating a sense of urgency, people uses crisis as potential opportunities. This can be a positive force in companies, clarifying what the objectives are and what they are not.

How to use a feeling of urgency

Most of us feel like we have too little time and too much to do. So, what should we prioritize?

it is very easy feel productive when you’re doing sector I tasks. You might feel like a hero, saving the day. You can avoid prioritizing since THIS is so important. But often, it’s not that productive. Too many sector I tasks are in sector II since you failed to complete them before they became urgent. This is also one of the points Kotter makes – you shouldn’t wait for the crisis to happen. You should sit, passively and just hope that things turn around. In other words, prioritize sector II tasks.

If you spend too much time in sector I, you can start thinking that sector III tasks are sector I tasks. You are so used to working with those hectic tasks that you fail to recognize what is important and what is not. You see something urgent and without really thinking, you take for granted that since it’s urgent, it is probably important too.

I’m currently working on an important project. It’s very important that we deliver on time and with the right content. And I want the people involved to feel a sense of urgency. This doesn’t mean that all the requirements are urgent or even important. These prioritized must be fully understood by the developers. By making them feel a sense of emergency, I also hope they can use this feeling to become more creative. This does not mean cutting corners and pushing defective code. It means that they can come up with new brilliant ideas and also discuss when they think that something is very time consuming so we can decide if it should be cut or not.

But the feeling must be shared with others. If other coworkers does not feel the urgency, they can easily distract my team with those sector III and sector IV tasks. It is so easy to see your own deadlines and tasks as important, but how important are they compared to other stuff? Context switching is one of the best ways to ruin a project. Once, I had a developer assigned 5 hours a week on a project. I declined. The context switching for this person would not make him productive and the others would spend too much time updating him every week. And how could he ever get that feeling of urgency if he had three projects at the same time?

My own conclusions are:

– Don’t mistake Kotter’s definition of urgency with the 7 habits definition

– Make Sector II tasks feel urgent! TDD, BDD, and what ever strategic software development techniques you wish to use must feel urgent, otherwise they will not be prioritized and then developers can start to think that the quality isn’t that urgent

– It’s hard to get a sense of urgency if you context switch too often

– You cannot get a sense of urgency if you’re alone with this feeling

– Developers will never feel that sense of urgency if they don’t feel and understand the objective. Excluding them from these discussions is contra productive.

Any other thoughts?

Is it a project, or a product, or both?

I guess it’s not an uncommon problem. You have a project with a fixed and very important deadline which you cannot miss. But the stuff you’re building, you really want this to work for the future so that you can re use the stuff for other projects.

Since this is a scrum project, we only have one product backlog and all the items have a unique priority. So, how do you prioritize the long term value? In agile and lean software development, you want to build stuff as simple and easy as possible. But in this not uncommon scenario, “simple as possible” is not only regarding the project vision but the future projects. And these are not in the far future; one of these projects are probably starting half way through this project. So, this is something we need to plan for and take into consideration.

The best way to view this is from a product company’s point of view. The same scenario is common if you have a company who sells products but also custom built applications.

Here goes. You work at company which have the product XCV:P. And in walks a customer who wants to buy a custom application; Alpha. As a product company you can see that the output of this project can be used for XCV:P. The investment is big, so you really want the customer to pay but he only wants to pay for the stuff he needs for Alpha. If you end the project and the requirements of Alpha isn’t met; the customer won’t pay. But it would be crazy of you as a customer not to adjust the content so that you can’t use it for XCV:P.

So, how do you do it?

First, you need a project manager who understands both the need from Alpha and the need from XCV:P. But he must never risk Alpha to meet XCV:P. This is very very hard and require constant discussions and feedback. Second, the developer’s must grasp these long term and short term needs. You’re in for chaos if some of the developers think the objective is Alpha and others XCV:P. They need to know where the cash come from but they should also understand how beneficial it would be for the company if we made things nice for XCV:P too. Don’t try to hide this complication; expose it and let the developers handle and discuss it. We will probably need a product vision and a project vision.

In my non fictional project struggling with this complexity, I will use the allegory of the product company when presenting the project to the developers and I will keep the idea in my head when I work on the probably hardest task on any project: priorities. This is a project, and a product and we will need to handle that. But this is also what makes this a really fun and interesting project as well.