The Importance of Removing Impediments

What is an impediment?

I do not actually know, because it is such a difficult word. But what I do know is that the time I have to wait for a build to finish is not productive for me. It even costs the customer money. This is for me an impediment.

If the time it takes to build the application is too long it starts imposing challenges on me. When it takes too long I do not want to build too often.. If i do not build too often, the tests is not run often and I will not commit code very often. This leads to finding bugs much later than I normally would have if I had ran the build more often. So I use more time fixing the bug because I have produced much more code since i made the bug somewhere in the huge codebase.

Did you get it? If not let's run som numbers on it instead. Lets say that it takes 8 minutes to build and that you use most of the resources on your computer while doing it. The best you do is drink a cup of coffee or read up on some documentation while you wait. Let's say you do the cup of coffee and wait for 8 minutes to see if the tests fail or pass. Its not only you in the project, but ten people that does the same thing. We all do it 2 times a day, because it takes so much time and we dont like coffee that much. We do it every day of course. So the numbers become:

8 minutes x 2 times x 10 people x 5 days = 800 minutes = 13.3 hours

Not only does it take you 16 minutes a day to build, but it takes the whole project 13.3 hours to build a week. Let us then say that you work 40 weeks a year and your project runs for 2 years.

13.3 hours x 80 weeks = 1064 hours

So during the lifespan of your project it has been used 1064 hours for running the build. What if those hours could have been used to implement more functionality because you have so much good code that your build did not take any noticable time at all. Imagine that the cost where 1000 NOK per hour that would amount to 1064000 NOK used on build/coffee during the project.

1064 hours x 1000 NOK = 1064000 NOK

That is not just an impediment to me, but to the customer. Build time matters! So remove those impediments while you still have time left to do so. If you are not busy building the application of course...

Maintenance project?

In software engineering, software maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.”(ISO/IEC 14764). [Wikipedia]

I have been bugged by the term maintenance project for a long time and it is time to vent the frustration here. The project I am working with has two parts, one for development and another for maintenance. While the project is called a maintenance project we actually do produce a lot more new functionality than correcting fault and adapt the product. Many projects are in the same environment and it is unfortunate that they are called maintenance project when they actually should be rid of the term maintenance. We do maintenance as well, but not to the extent that it should be reflected in the name.

The reason I bring this up is because maintenance is not a popular word and people start to get all kind of ideas when they hear the term. People often say that maintenance projects does not use any new technology, they do not do anything exciting (from a developers perspective). Well this is in our case wrong. We do new functionality every day and we make use of some of the newest technology out there. Our code grows and adapts with new technology.

Let me mention some of this years improvements to the code and environment:
New platform: Moved from IBM Websphere to JBoss.
New JDK: Moved from IBM JDK 1.4.2 to Sun JDK 1.5
EJB2.1 to EJB3
.Net1.1 to .Net2
New EpiServer version
RAD to IntelliJ
..and a lot more!

I think one of the important tasks in a project is using new technology, not for the sake of having new toys, but to be able to move forward. The changes we made in the project have made new functionality possible in new and better ways for our customer.

So my suggestion is to stop using the term maintenance when the project delivers more than 70% new functionality instead of maintenance as defined at the top of this blog. Make room for new technology in you project not only for your own motivation, but also for the sake of your customer.

Getting things done..

You have heard it before and I am saying it again. When you got a lot of things to do it's easy to loose focus. As a project manager its imperative that you have focus on the prioritised tasks.

I'm what you can call a "yes" person. When people ask me for help or wants me to do something for them I tend to say yes. This keeps me interested in work and it often puts me in positions where I can learn new things, meaning that being a yes person is great. But sometimes the amount of things I have said yes to gets too big. Thats when I start to loose focus on what I need to do, especially what to do first. When this happens we ask ourselves questions like, what is the most important task or which task has the nearest deadline. These questions are important, but what you need to do first is to actually know what tasks you have said yes to.


Make a list!

It's often as simple as that. Just make the list and things becomes much more clear. Then add deadlines on the tasks and prioritise it.

As a professor at the university I knew said, when you know what to do there is only two more things: First thing is to start and the next is to continue!

Not that different from scrum now is it?

Some inspiring webpages on GTD and the like:
Coaches corner
All things Workplace

Work Engagement

In my last post I talked about fear as an obstacle to be productive in development of a software project. Knowledge can conquer this fear, but there is also something else that can make people forget their fear. Engagement!

If you are really interested and motivated in your work you might just not be afraid of the huge codebase and the possibilities of errors and bugs when you do a change to it. In my opinion a motivated person often learn faster and are quicker to pick up on positive changes in their environment.

I often feel an "energy" when doing something interesting and it keeps me motivated. I read different blogs and I buy both management and system engineering books. This keeps me interested because I am constantly learning something new. But it is not what makes me actually tick, what does it is the actual tryout of an idea. Even if you only read it in a book or a blog. Does it work? If it does work it spurs me further in to the idea and I get motivated to continue to try new ideas.

How does one motivate others in the same way? To some extent I think it happens automatically when they are close to, or are working together with a person that has this energy. But is it enough?

My advice is to bring your colleagues or friends to the spot where you get your motivation from! Be an enabler and the motivator. Do not be afraid to bring new things to the table. Enable for others to bring new ideas into the work environment.

A day that nothing new is tried out can be a wasted day.. Can work be performed better for you and your company in any way?


Some of my favourite places to get ideas and inspiration:
The Practice of Leadership
Management Skill Blog
Management Craft
Agile Leadership
XP Meetup
*Technical*
Uncle Bob
(++)

Estimation

Have you ever lost track of time after saying to someone (your better half maybe?), it will only take a short while. Then suddenly dinner is cold and a couple of hours have passed, at least. Is this because you did not know how long time it would take to do the things you had planned. Maybe your definition of a short while is different than your better half's definition? Maybe the planned things where not the actual things you had to do anyway.. We estimate in our living life everyday, how long will it take me to get there, how long will I use to make dinner or how long will I use to answer these emails and send them.

It's a well known fact that we tend to be overly optimistic when we do estimation, especially if we are planning to perform the task ourselves.

In our team, we just started with planning poker. Before we did some estimation with post-it notes using numbers on them , but not all in the team where involved in the process. Before this we normally have the ones that where to implement the changes, estimate the time it took, without much discussion other than project manager adding to the estimate with test and administration time (yes most people forget about time to test).

Questions that often comes up is, who are doing the work? Normally I say that we estimate how long time the team will use on it, how long will it take us to implement this feature? Often someone know something the others do not and this makes this person able to perform the task faster. This does of course create an even wider gap between the people in the team. By estimating together with the planning poker cards we open up for others to more easily try themselves on tasks they normally would not be able to get because someone in the team where better at that type of technology than they are. By this I mean that the estimate opens up for other people to have a chance on making it within the estimate. This makes the team much better suited for the day that one team member leave the team or call in sick. We are then actually still able to perform the task with less problem than if noone had ever touched a similar task or that specific technology.

Questions I want people to think about is:
How long time does it actually take? What is the estimate used for? Do we need the estimate?

These questions put a big questionmark behind the word estimation. Normally in our case the estimate is used for giving the customer a rough idea of the cost. Can this really be turned around as many people talk about in the "agile community", are we able to get the customer to come to us and tell us how much they want to use on the new functionality. Do we have enough trust to deliver what we can in the time we have available. With the Scrum approach we surely would be able to do the important tasks first, but is it enough?

Another question that shows up is how long does the estimation take? Maybe much of the estimation we do should be considered as a waste of time. David J Anderson has some nice words regarding that perspective here.

Friction and slow delivery

I was just reading up on my favourite blogs when i came over a interesting post on the From where I sit -blog. Michael S. Hyatt describes what he sees as friction when visiting a bookstore. The idea is to get the purchase happen fast enough so the customer does not change his mind or as in Michael's case, leave the shop because it took too long to get the purchase done.

Could we not draw parallel from this to our development of software and project practice? The customers want a new feature in an already developed software. We receive the request and we specify it further with the customer. We estimate the time it will take to develop the new functionality. Customer gives us clearance to start working on it. We work on it. We finish the development on the new feature and we test it. We do not deliver it, because we have more things on our list to do in this release. The customer knows this so he is patiently waiting for us to finish this as well, because he also wants the other changes. We test the other changes, we might find a bug and work more on the issue. Then we hand the release over to the customer so he can test it, this is 6 weeks after the order was placed. They find a bug which get reported back to us and we start fixing it. We deliver a patch for the release and they test this. All is well and the testing is over, the release goes to production. The users finally see the new feature which they wished for, maybe 3 months ago.

What if the process where a bit different? What if we develop the new functionality and test it and deliver this to the customer. The customer tests the new functionality while we develop the other requests on the list. The customer find no bugs in the functionality and we release it to production. Or if the customer finds a bug, he reports it and get a new release from us with the fix and maybe more new functionality in it. Maybe some of the other things on the list was finished and tested in time to get it with the fix for the new functionality. Customer gets the new delivery and test it again, now with additional functionality. It goes through and we release it to production, maybe 3 weeks from when the users wanted the new feature.

To me this sounds better than the initial way of doing things. If the functionality that gives value to the customer is done, give it to them! If the users want changes, make the change and deliver it to them as fast as you can. No need to wait.

There are of course issues around this. One of them being the ability of the customer to actually receive and test the new functionality as fast as you deliver it. Another might be that the initial software is used 24 hours a day and a production release will hinder them in their work and cost money. But I urge people to think on this and ask their customer if they really cannot receive and test small parts rather than big chunks of functionality. Do they really want to wait that long for something they ordered? Why should they order and add all these orders in to one delivery? Does 15 minute downtime on their production system really cost that much versus having users waiting for functionality for months? Do their lack of motivation towards the use of the system cost less?

In this post I have not even started talking about the cost of long feedback loops on the delivered functionality. I'll save that for another post sometime.

Rationale for the change

Change can happen in many ways and there is so many factors involved. As mentioned on my favorite leadership blog: Leadership in Practice, change fails when employees dont grasp the rationale for the change. By rationale meaning the why in the change. Why is it happening? Does the change only happen because some leader have found out that this should be better for the employees or its the latest hype? Head over there and read the post, it's a good one.

As i commented on George Amblers blog, it is more than just the rationale in change. It's the what and how as well. Many of these decisions should be taken by the employees afflicted by the change. They should know best how to perform changes. At least most of the time.

Maybe its naive to think that way, but to believe in people make them do incredible things.

Are the customer involved enough?

A while and several blog drafts since my last post now, but here it is.

The question is really, are the customer enabled to be involved enough? While we are quick to think if the customer are participating in creating the backlog or the sprintlog. By this having ownership in the decisions made. Not long ago on InfoQ Little and Spayd gave their views on agile and organisational change and they mention the importance of the customer being part of the agile process if the deliveries are to be successful. This is very true, but are they ready in their organisation to handle the deliveries?

As the Agile Manifesto principle states: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This assume that the customer are able to handle these deliveries at the pace they are coming. Further the manifesto claim that Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. If we are to adhere to these principles we have to enable the customer to also become agile in their process of receiving the delivieries.

To take a practicle example of this I can relate to my current project which is in the process of implementing a more agile approach. Agreements have been met and deliveries have been delivered, but the receiving end are not able to handle the deliveries at such a pace. They lack both the manpower and the routines to test the deliveries thus bringing us back to how it was before. The team cannot keep on delivering while the tests are not being managed and we have to set a new pace. A good article on Agile Journal describe this scenario as candy coming faster on the conveyor belt, it creates trouble handling them.

This shows that agile processes sets new demands to the organisations not only where the deliveries are being produced, but also in the receiving organisation. Now you have not one, but two organisations that has to adopt agile. The question is are the customer involved enough to make that change?

Make it better

Easter vacations are over and we are finally getting back to work. I have a few exciting things happening this week as my role as project leader is getting more familiar. One of the things is a full day unit-test workshop with my project members.

Testing we do today:
1. Your own testing when you have written the functionality
- Verifies that you do not have any obvious errors
2. Someone else tests the functionality after your description of how to test it
- Verifies that you have not skipped the testing? Sometimes people do different approaches here..
3. We run a robot-test on main functionality of the solution.
- This ensures that we do not have errors that stops the solution or influence the core functionality.

After this our solution leaves the office and is delivered for testing by the customer.
This approach would work great if it had not been for the time between our beginning of the programming/coding and the time we get feedback. It has a high risk of creating a gap between what the customer wants and what he gets. To help with this gap, we have iterations in the implementation phase which is highly influenced by customer feedback.

All well and good so far.

The issues start showing up in Jira (our bug tracker) some time later. This might be issues connected to integration or even several years old code. The amount of code lines and the number of integration points are increasing every day. To avoid the problem of having feedback this late I think we need to increase the release cycle and write unit-tests before we code. The "write the test first" (or TDD) rule will enable us to think differently before we start coding. As well as seeing implications earlier and taking these in account when implementing our functionality. One of our goal is to increase the quality of both code and functionality and this will work as an enabler. After doing this a while we will hopefully be able to start with nightly builds and catch more bugs this way.

Oops..This post got a bit more technical than planned, but anyway thats the main thoughts.

You might ask "why we need a 1 day workshop on this?". The keyword is ownership and engagement. If I just say that we are from tomorrow writing tests before we code new functionality, who would do it?
By doing this together we lower the barrier for something new and we increase everyones competence by working together on the different problems that comes up. We have focus on this for a whole day and might actually remember it.

The ultimate goal is an increase in quality and pride in what we deliver. Even if we work with legacy code and others mistakes, we can make it better! And we will!

Scrum - something for maintenance projects?

Phew.. Been a couple of busy weeks. I have just become the project leader in a 5 person project. I've been in this project with various roles since I started in May last year. This is a great opportunity for me to be part of something and to change it to something better if possible. Not that you always need change, but I tend to think that change is good in so many ways that some changes should be made in order for people to stay with a project over a long period of time. I really wonder why so many people do not want such a job. The possibility to be a change-maker!

The challenge in our project is that it is an "old" project by IT standards and it is in maintenance phase. The project consists of 5 people in a good blend of experienced and not so experienced. Me being part of the latter when it comes to my new role. What I find interesting is the energy I feel about this! I've always felt that I put out the questions to my surroundings. It now seems that I will be put to the test myself and have to do action based on others questions and requirements.

Hopefully I will be able to change some elements in the project so that we can work in new ways and see change bring new energy in to the project. I have a dream about an energic group of people working together to make the best they have ever made. When we deliver we should be proud of what we have done and feel that it was worth it. This is a bit childish and naive, but I think it is possible if one can create the right circumstances. It can happen! I really look forward to work with the people, the environment and the product from within this role.

With this perspective I have looked to Scrum. I see elements in Scrum that can be usefully applied in our project. These elements being the product backlog, sprint backlog, daily scrum and burndown charts. Especially the sprint backlog as this will allow developers to focus on these issues and then the burndown chart to see the progress and make it possible to feel that we are moving toward a goal.

Our project is in maintenance phase which I find exiting for this kind of "method". This means we have bugs being reported as well as new functionality into Jira. This will be our starting point when we begin to work on our product backlog.

So there you have some of my thought on change in our project. Maybe someone have seen Scrum used in maintenance projects earlier and would like to give a comment?

Work Environment

On Friday we got a presentation at Computas by Sintef. The topic of the presentation was work environment and workspace. By this meaning office layout and its implication on efficiency, productivity and identity. They had an interesting perspective on how we where behaving in different workspace solutions. One of the points i picked up was the difference between a workspace geared for communication versus concentration. Cell offices works best for the latter and they had seen increase in communication with open office solutions. This created reactions in the audience which today have cell offices, but often with an "open" space between their offices. The offices are also occupied by people working on the same project. It was mentioned that the walls toward the open space was made of glass. Only that most people sit with their back to the door and the glass wall and the open space between the cell offices.

I think moving around is healthy for your own motivation and inspiration. I also think that open office solutions is one of the better solutions for knowledge workers. Here is what I wrote in my master thesis on the subject:

Work Environment
As an important facilitator of knowledge sharing Davenport and Prusak (1998) mention the work environment. They claim that changes in the work environment may cause loss of knowledge and it can also disrupt the existing sharing process. Knowledge has a tendency to thrive only in the environment it develops. Elements mentioned are, “organisational size, focus, management and intangibles as trust and atmosphere.” In the previous section organisational structure and size was described as an influential element to the way a knowledge worker performs. Knowledge workers often collaborate in different ways and use communication tools as well as face-to-face communication.

Office environment needs to facilitate the collaboration and exchange of tacit as well as explicit knowledge, Davenport (2005) mentions meeting spaces and conference rooms as a minimum. He goes further and suggests, based on findings by Thomas Allen (1984), that knowledge workers who need to communicate should be located physically close to each other. Becker and Sims (2001) claim, “The more open the environment, the more frequent the communication and the shorter the duration.” In addition to this they say that the communication in such an environment is “not viewed as interruptions, but these short, frequent interactions provide very fast feedback and shortresponse times, allowing work to move forward overall.” The data from Becker and Sims’ report also suggest that more visual contact actually contributes to fewer unwanted interactions, by “changing not so much the frequency as the timing of serendipitous communication.” By this they mean that by having visual contact the workers can see if the others are busy and not interrupt. On a more organisational level Allen (1984) claims that knowledge workers work environment should have aspects from the departments that work with Human Resources (HR), Information Technology (IT) and facilities organisations. These aspects together can create a thriving working environment with elements important for atmosphere, communication and the use of process supporting tools.

References

Davenport, T. H. and Prusak, L. (1998) Working knowledge : how organizations manage
what they know, Harvard Business School Press, Boston, Mass.

Davenport, T. H. (2005) Thinking for a living : how to get better performance and results
from knowledge workers, Harvard Business School Press, Boston, Mass.

Allen, J. T. (1984) Managing the Flow of Technology, MIT Press, Cambridge.

Becker, F. and Sims, W. (2001) Offices That Work - Balancing Communication,
Flexibility and Cost, October, Cornell University.

Management Style

My previous post about Team Learning put requirements on the management. How can one manage people that know the job better than you or even work in their own way.

Management style is often influenced by organisational structure and reflects in what way the workers are coordinated. On the note of managing people Drucker (1999) mentions “that one does not ’manage’ people, but the task is to lead people.” And the goal is to make the specific strengths and knowledge productive of each individual. The more skilled and proficient a worker is in his work, the harder it is to manage this activity according to traditional management methods. A direct supervision approach requires that the supervisor have more knowledge or is more skilled than the worker to be able to know what the worker is supposed to be doing to get the wanted result. Due to the mentioned change towards more knowledge work in organisations today, Drucker claim that one does not need supervisors(13), but a leader –or put in terms of today- a coach(14).

Both Drucker (1999) and Wenger (2004) describes that their view of knowledge management begins with managing oneself as a knowledge worker. Take an active role towards your own learning and increase of knowledge. Peter Senge (1992) sees managing oneself as personal mastery, and by this meaning to developing one’s own proficiency. “Personal mastery is likened to be a lifelong journey with no ultimate destination.” He tells us that such a journey consists of processes whereby “a person continually clarifies and deepens personal vision, focuses energy on it, develops patience in seeking it, and in this way apparently increasingly views reality objectively.” This ownership and involvement leads people to do positive things towards achieving personal vision. Further personal vision is described as a calling of intrinsic desires, not a purpose to pursue. Senge claims as result, “People hold a sacred view of work because work now is valued for itself, rather than posing a chore that needs to be done as a means to some other end.“

People with high personal mastery “tend to be committed and exude initiative, have a broader and deeper sense of responsibility” in their work, and as Senge claims of key importance, they learn faster. This gives strength to the belief that answers to organisational inefficiencies lies not only in technology. Technology has often been seen as solution to efficiency and automation of traditional repetitive tasks. Furthermore information technology has enabled new ways of communicating and changed many of the traditional crafts and professions.

*13: Mintzberg (1983) claim that direct supervision requires close personal contact between manager and the worker, with the result that there is some limit to the number workers any one manager can supervise.
*14: Coaching has been used in sports and has become increasingly used as a management style in business the recent years. More on coaching see: http://en.wikipedia.org/wiki/Coaching

Motivating Workers

I've always ponder around how to motivate people. To me it seems there are a few guidelines in general, but as with much else you need to tweak it to fit with your context. Kathy Sierra wrote a few interesting lines on passion for work here. And when reading it I found a few other blogs that where interesting. One of them being David Maisters blog and another being Christopher Marstons blog, both giving good ideas on how to "manage" people. They are all well worth a look!