More on MindManager

Thank you for the comments on my previous MindManager blog entry!

Granted, performance issues can certainly depend on many different factors. According to my information the majority of the users don't seem to have performance issues. But there also seem to be a non-negligible number of users who did experience those issues.

However it is no help to the latter group of users if the former group of user have performance issues.

In my particular case when I observed the performance problems

• There was enough free memory (hundreds of MBytes)
• There was enough free hard disk space
• CPU usage was less than 10%
• No network usage
• No disk I/O

That basically indicates that probably more than one thread is running and a lock conflict is happening with one thread waiting for the other. Eventually a time-out will occur and the software continues to run. This is just a guess based on my observations, and the real issue might be a completely different one.

If you have used and developed professionally many different software products over 15 years then you start to get a sense for when a software has an issue. If a promise is given several times ("Update and the performance issues are resolved...") then I simply stop believing it. Instead of asking me to pay for an upgrade that solves an issues I would prefer to get a properly working version in the first place.

Anyways. Too many words already spent on the subject. I will consider giving version 7 a try.

MindManager, Performance, and Other Issues

For gathering new, complex, and broad areas of knowledge I found mind maps to be a very efficient tool. Although drawing on paper is often faster, an electronic version has it's advantages, too. As a product I use MindManager.

I have been using MindManager from MindJet for a several years now. Performance has always been an issue, but admittedly the featureset has improved over time. Each time there was a new version the company promised that the performance issue would be addressed.

I can't remember which version I started with. I upgraded several times, and currently the version number is 6.2.399 Service Pack 2. The performance with a map of reasonable size is poor. My laptop has no CPU usage, no I/O, plenty of free memory, and no network activity. When pressing the "Insert" key to add a new topic, it is as if the product doesn't do anything at all. It can take many, many seconds until it does something.

Of course I did complain to technical support. The people were very responsive. They suggested to switch off hardware acceleration for the graphics adapter. I tried that, and it helps. Sometimes.

Some observations:

• Suggesting to switch off hardware acceleration is basically like saying "Yes, sure did you buy the Ferrari, but adding our add-on allows for driving in first gear only." I didn't pay for a laptop with graphics hardware acceleration just to hear from a software vendor that I shouldn't use parts of it. That's not what I would call protection of my existing investments.
• Why is it that other software vendors are able to write software that has no issue with hardware acceleration?
• When I disconnect from the network and/or run the computer with batteries, the performance becomes even worse. I have had instances where MindManager didn't respond to user input for 15 minutes or more. By then I decided to kill the program. What has the network to do with graphics hardware acceleration?

A more "minor" issue is the function "Balance Map". If I could only figure out, what it is good for... When I click it, it rearranges the topics, but I can't find that the map is more balanced... Usually I have to print it on larger sheets, or I have to use a zoom of 38% instead of 50% or so.

Now, MindJet has made available version 7, and they encourage me to upgrade. Of course I have to pay for the upgrade. Why should I trust them that the tool has really been improved? Why should I pay for an upgrade if I cannot even get the existing version in a status that allows me to fully use it?

Given my experience I might just go for an open source tool or try a competitor. Maybe there are competitive cross-update offerings... Maybe I try FreeMind. They even claim that their software is faster to use than MindManager.

And another story

Let's see who thinks this time that I'm telling his/her story...

Again, I met a friend, let's call him Peter. Does he really exist? I don't care as that is completely besides the point. It is more about the story which, again, I have heard more than once from different people. In this case the first and the last account are several years apart.

The story goes like this: Peter is working for a consulting company. They developed and delivered a system that collects certain information across large geographical area. Part of the solution is using mobile devices for this, and once per day the data is transferred back to the head quarter to a central server.

The problems started when they started to work on the part of the software that deals with the transfer of the data to the central location. The firewall settings and the security policy of the company didn't allow for a direct connection, not using SSL (or any other secure means) and not even to a server in the DMZ (Demilitarized Zone). Then Peter asked whether they could sent the data via email, e.g. as an attachment which could then be picked up by a server. This solution wasn't acceptable either. Peter's client started internal discussions, and the went on and on.

At some point the delivery date of the project was at risk, and Peter couldn't wait any longer for a decision to be made. He had to come up with a solution.

Peter discussed the problem with his team. After some lengthy discussion, back and forth, they found the solution:

• Print the data
• Fax the data
• Enter the data

Yes, you are right! Faxing was ok. And then some people in the headquarter of Peter's customer would take the received faxes and enter the data manually! Crazy, but it saved the delivery date for the overall system.

Update: In the meantime the customer has settled on a much better solution and the data is now transferred via SSL to the DMZ, where it is picked up and transferred to the server within the firewall.

Morale: Sometimes you have to be very creative and adaptive to make the deadline. I think Peter and his team were very agile!

Where my stories come from

Once in a while people ask me where I get my stories from. Well, there are many different sources but most of the time they develop as I talk to friends.

All the stories I tell in this blog are inspired by true facts and data. However, in order to protect people and companies, I never tell a story that is based on a single account only. I know people working for over 25 different companies from all over the world. Only when I hear a similar story at least twice from different companies I assume a pattern. Then I take the information and use it as an inspiration for my blog.

Sometimes there is also a large difference in terms of when I have heard the different stories. One story I might have heard many years ago, while a different one I just came across recently. Together they may suggest a pattern. One story might have been from a very small compay, and a different one may come from a very large one. One story might be from Europe, and the other from India or Australia. These stories are particularly interesting as they may reveal cross-cultural patterns.

I ask you for your understanding that to protect my sources I will not reveal any names, locations, times, or other specifics that can be used to identify a company or a person or a source. Only where I have the expressed permission from a person or company I can give more specific details. Generally the names I use are not the real names.

Or as they say at the end of the movies: all my stories are inspired by real facts and data, but any resemblance with actual people, companies or events is pure coincidence.

The ripple effects of moving in a release date

When a project is behind schedule several options are typically considered. The schedule is adjusted, the number of people working on the project is increased, or the scope is reduced.

A few days ago I met Susan, an old friend of mine. She is working for a very small software company, and she told me about a project that she used to work on until a few months ago. The project was an online reservation system for hotels, and as the hotel owner decided to go into business sooner than originally planned the schedule for the project had to be shortened by a few weeks as well.

This decision caused a number of ripple effects, mostly undesired side effects.

First it turned out that the staffing level wasn't high enough to achieve a sufficient velocity for the shortened time line. Additional engineers were required. As the company is only a very small outfit, they had reassign engineers from a different team to this project team thus sacrificing valueable work in the other team.

This in turn not only reduced the velocity of the other team. As a consequence the scope for the other team's deliveries had to be reduced.

Also, it turned out that in order to make the shortened deadline the project team had to take a number of short cuts, e.g. by using a less elegant design in some places or by not refactoring code to the degree it deserved.

There were many more impacts, but so far we have:

1. Need to increase staffing level in the project team: additional project cost
2. Need to reassign engineers from the other team: cost in the form of delayed deliveries in the other team
3. Need to clean up the "short cuts" caused rework after the release

Bottom line: Moving in a release date had not only the immediate impact but also cause a number of side effects, each of them causing a number of additional problems and/or cost.

The software has been released a few months ago, and the project team is onto a new project. My friend reckons that it probably will take a few more months until the effects of the changes have been resolved.

On the positive side, Susan's team delivered on time and with functionality and quality as specified. In addition the customer is very happy with her company's ability to adapt to the changed plans. Susan and her colleagues are, however, very aware of the price they had to pay.

Apologies from Agile 2007 Conference Program Committee

In case you have submitted a paper, tutorial, etc. for the Agile 2007 conference, you most likely have noticed that the submission system had a system error. Here is a message from the conference chair on that regard:

I am finding as many opportunities as I can to express sincere apology for an error in the Agile 2007 submission system which caused multiple
accept/reject messages to be sent out. While all of us have experienced errors in our software projects, this is one that inconvenienced many people... for this, I apologize.

We can point accusations at the software developers and testers, but it will not accomplish anything. Instead, it is more effective to correct the error and move forward. We have sent revised accept/reject notices (with an apology) and will make every effort to learn from this experience.

We hope that this mistake will not cause you to overlook the countless other things our hard-working team of volunteers are doing so well in order to make the Agile 2007 conference fabulous in many, many ways.

Mary Lynn Manns
Conference Chair, Agile 2007

Being a member of the program committee myself, there is nothing I can add.

Fingerpointing, however, will not help. Instead, it is important to look at the situation, make the best out it, and move forward. I think Mary Lynn and the other members of the committee are doing this. We all want the Agile 2007 conference to be a success!

A Really Short Release Cycle and An Impressive Quality

Just came across a blog entry by David J. Anderson. His company releases every 9.5 business days and with zero defects since January 2007! Impressive!

Agile Certification

In a recent post of a position paper on "Agile Certification" the chair of the Agile Alliance describes the various aspects of whether a certification for agile practitioners should be introduced or provide value.

I'm convinced that there will be people who believe that certification provides value to them for recruitment purposes. With the teams I work we use different means to determine whether a candidate fits the team. That by itself is already a statement: We don't look for certifications, we look for "good fit". Someone can have all the certifications on the planet, we will not hire that person if he/she is not a good fit for the particular team.

Just the other day we had an application by a candidate who used "throw new NullPointerException()" in the programming task. In this particular case we tried to imagine what would happen if we had that bit of code in a deployed system, and the exception fired off... No certification in the world can prevent that, and in the particular case we didn't consider the candidate any longer.

Here are some other things we do when we assess candidates:

• Pair programming session
• Programming task
• Design session
• Google search (if the candidate is claiming to be an active member of the community)
• Peer interviewing by members of the future team
  

I'm sure that this approach is not perfect, but so far the results speak for themselves. For us, I don't believe certification would make a big difference.

In the teams I have worked with I have met accountants, biologists, former HR people, and many more different professions. All of them had degrees and certifications, most of them in areas other than software engineering. And still, all of them were excellent software engineers!

And then, there are the companies that get ISO9000 certified. Sometime people I wonder what that is good for except for becoming supplier for certain companies. Does it mean that the quality improves or the productivity? It might, it might not. The ISO9000 certification certainly doesn't guarantee that. There are companies that are ISO9000 certified and still deliver crab, and there are companies that are not, and they deliver outstanding quality.

Hey! I tried to lean towards the more provocative end of the spectrum in this post. So if you, my dear reader, have a different perspective, I would love to hear from you!

Embracing Change: What Stays Constant?

My experience is that many people like to have something that doesn't change. Sure people understand that to stay in the game, we need to adapt as quickly to new situations as possible. Only if we are fast enough, the ability to adapt can be turned into a competitive advantage.

But then I observe the people I work with, I observe myself. And I discover that they as well as myself, we are still looking for something that stays a little bit more constant.

And when we take a closer look there are things that stay constant. We change the tools, we change the architecture, the designs of systems, and retire tools in favor of better tools. We change the techniques and processes. We create a flow of all these elements of software engineering. And yet, there are things that stay the same: It is the values and principles that we apply. The people I work with, and myself, we have chosen the agile values and principles as a guideline, as a foundation for how we work. They provide us with the foundation, with that sense of fixture.

Some of the more traditional projects and teams that I have seen in the past, they, too, have things that stay constant and things that change. They often have chosen the process to stay the same, for instance with all the artifacts that people create, but which sometimes don't provide as much value as they require effort to create and maintain them. And the thing that changes are the values. Sometimes they claim that they respect the human individual, their people's dignity. But then, during the execution of the projects, these are the things that go overboard first. With pressing deadlines people are overloaded, with a shortage of people, contractors are parachuted in, with problems popping up here and there, people are moved around (ever heard of a "Move Meeting"?). Should we as leaders really be surprised, if no hand shows up when we ask the question, whether people feel treated as being human individuals?

There is better ways, and one of the questions we should continuously ask and answer is which elements we want to keep constant, and which elements are the ones where we want our teams to be adaptable. If we decide to keep our values and principles constant, and want to change the way we work, the technology, the design, the tools, the processes, then we are usually in a much better position for success! And all people on our team and the stakeholders will have more fun, too!

P.S. I had a very good discussion today on this subject. Thank you Raymond, Mark, and Curt!

Reorganizing Agile Teams

When you work you most likely will go through a reorganization at some point in your career. It seems that in some companies it is almost a habit to roll out the next reorg before the current one is complete.

I often wondered whether frequent reorgs are a good thing or a bad thing. Until a few years ago I thought that because people are affected reorgs should be kept to a minimum. After all there is always someone who looses and someone who wins in a reorg, isn't it?

My team has helped me to learn better. The current project is now almost 20 months old, and I can't recall all the changes we had in our internal team structure. Many different factors caused us to change the team structure. Let me highlight just a few of them.

Scope: While the overall project objective wasn't modified a lot, the plan for achieving it changed a lot. Starting with a huge legacy code base (over 3 millions LOCs) we thought that using tools was a good idea to move to a pure Java implementation. So we organized the team in several smaller groups, each of which attacked the problem from a slightly different angle. For instance one group focused on how the code base could be restructure, and a different group was looking into converting screens from an old implementation to the new one. In doing this we learned that the automatic conversion wouldn't work for us for various reasons. So we decided for a new plan, and luckily we had the management support for now rewriting the application from scratch. Not an easy thing to do for a small company! As a consequence we changed the structure. I can't recall any major issues on the people side. The team understood that we had to adapt how we worked.

Team size: In August 2006 our little company was acquired by First Data Corporation. After the initial issues that typically follow an acquisition were solved, it was decided to increase the size of our team, and we started hiring. At that point the team consisted of two groups and each of them worked mostly independent, but we rotated engineers once in a while to keep the architecture and design of the system simple, and also to promote reuse across the groups. With the increasing team size we have realized that we had to change again, and therefore we regrouped again. Now some of the groups are almost too small (just one or two pairs). However, we have currently 16 openings (see First Data Utilities' website) and so the groups will eventually have a good size again. It's too early yet to tell whether the new setup will work for us.

Team maturity: Initially we had three co-located subject matter experts. Over time as the team matured and the interaction between the subject matter experts and the software engineers intensified, we realized that the subject matter experts were becoming overloaded, effectively a bottleneck. So we added two more, and we plan for another one or two over the next 12 months.

These were only three examples of what leads us to adapt over time. In essence, we reorganized as necessary and we are much more flexible than in companies I worked with previously. So agile teams seem to be different in that sense too: They continuously search for better ways to develop software. This teams has proved that it is capable to not only adapt architecture, design, toolsets, process, and technology. They have also developed the capability of continuously assessing the team structure, trying something new, discarding things that didn't work, and keeping things that did.

In closing I'd like to encourage you, the agile leader, to try this with your team as well. It's not easy initially, but it works and pays off!

Are We Using The Wrong Tools?

Frequently I'm asked why software development can't be faster, cheaper, etc. and actually today I found some information on the internet that really made me think whether we are using the proper tools.

"The new features of the ... development environment allows developers ... to ... automatically generating 100 percent of their applications."

(Source: Oracle Investor Relations)

Now I wonder why we have software engineers in the first place....

How does working in an agile team feel like?

Sometimes people ask me what the difference is of working in a team that uses agile methodologies as opposed to traditional approaches. Well, that's hard to explain, but maybe the following helps to explain it a bit.

One team I work with collects quotes from their members on their team wiki. I'd like to share some of the quotes with you as they reflect the culture and mutual trust among the people working in that team. To protect the individuals, I have left out the names of them.

• "I would be very disappointed if [fill in a name] was that smart." (engineer)
  
• "I haven't done any work for quite a while." (engineer)
  
• "I have no idea, I'm just the story bitch." (on-site customer)
  
• "Think of your best pairing experience." (consultant/coach)
• "It's not really broken... There are different shades of broken." (engineer)
• "All services are topless." (engineer regarding Service-Oriented Architecture)
• "If you're ok to work by yourself then I will pair with you." (engineer)
• "It's not a random failure, it's a semi-consistent failure." (engineer)
• "I can think all I like, it still isn't going to get us anywhere." (on-site customer)
  

Working With Suppliers

Working with suppliers can be daunting. In one project however, we applied agile principles and achieved very good results.

Initially we discussed a traditional contract but in the course of the talks it turned out that all participants wanted to have something more flexible. So we put only the basics into the contract, e.g. rates, time frame, responsibilities, etc. With regards to the scope we only roughly described the subject but left the rest open. Principally the contract was time and material based, so admittedly required some basic trust.

Architecturally we were in the fortunate position that what the supplier was to implement could be "isolated" in a separate module with a clearly defined interface. So, we created the interfaces definition which was ultimately a source file plus a set of automated tests against those interfaces. Then the supplier knew exactly what was needed. If all tests pass he would know that he was finished.

If we would find that something didn't work as expected we would then augment the test suite and send it back to the supplier. He would then come back with an estimate of the cost and we would then decide whether we wanted it for that price. In some cases we negotiated, e.g. by asking what it would take to reduce the price, e.g. by slightly modifying the requirements (automated tests and/or interfaces).

Collaboration was improved by sending one of our engineers to the supplier once in a while and viceaversa. This, too, improved trust and communication and working together was much smoother.

Overall, we worked with that supplier for more than 2 years and the results were excellent. Trust was substantially improved and a required ingredient for the success. So in this particular instance, working with a supplier was almost as working with a different department in the same company.

Dealing With Uncertainty in Stories

Extreme Programming uses stories to define the scope of a system. Sometimes teams have difficulties to estimate the size of stories with a satisfying accuracy. Different approaches to address this issue are possible, e.g. making stories even smaller.

Another approach is to look for the elements in a story that represent the risk. Then these elements can be addressed in a time-boxed spike (or experiment). The remainder stays thus becomes a low risk story.

Risky elements may be new technologies that need to be tried first, or a cool new user interface widget. An example of the later could mean that you might want to implement a simple (maybe even un-cool) version of the interface first. And separately you play the story with the spike for the cool widget. That way you deliver value while at the same time pushing the envelope in a time-boxed fashion. If the outcome of the spike is good then you can play a third story to improve the user interface.

With this approach I have seen different teams addressing risk, and at the same time improve their estimation skills. There are certainly more techniques. If you know of another simple way to deal with this I would be interested to hear from you.

Cards Or Planning Tools?

In one of the newsgroups I monitor there was recently a discussion on Project Planning and Tracking Tools. I'd like to add another experience to this.

In a project for which I started coaching earlier last year, I introduced index cards for stories initially. People looked at it as something very "unprofessional". Paper and pen? How could that possibly work?

Well after a while the team decided that they wanted to introduce XPlanner. After yet a while some customers on the team decided that they were not exactly getting what they were asking for. As a consequence they started to put more details into the tool. Sometimes there were a lot of details even for how to lay out widgets on a screen and what colors to use. Screenshots of mock-ups were eventually added.

Yet another while later the team discovered that this didn't really help. Now the stories were very big and therefore hard to put into a short iteration. And the bigger they were the higher the likelyhood that they were underestimated. An extreme case was a story that was estimated at 47 units but which took 228 units in the end to implement. It actually consisted of a sequence of four stories.

It was clear to them that they had a problem. Now they have reverted back to using index cards. Writing or even drawing on an index card limits the amount of information you put on it. The team decided that the best and most important information on a card was the business value that the completed story tries to provide.

Having less details on the cards themselves has triggered more and better conversations or negotiations between the customer and the engineers. More options are discussed and it is much easier to move storie around. Estimation is better, and the geam gained more flexibility with regards to how to implement a story.

Bottom line: You might have an excellent justification to introduce a software based planning and tracking tool. But sometimes it is better to just go using simpler tools. If your team is co-located you certainly have more options, but even for distributed teams it is worthwhile to look for alternatives. Simple tools may lead to simpler and better solutions.

Question from Java Certification Test

I found this question at www.javaprepare.com.

Which of these is a correct fragment within the web-app element of deployment descriptor. Select the one correct answer.

1. <exception> <exception-type> mypackage.MyException</exception-type> <location> /error.jsp</location> </exception>
2. <error-page> <exception-type> mypackage.MyException</exception-type> <location> /error.jsp</location> </error-page>
3. <error-page> <exception> mypackage.MyException </exception-type> <location> /error.jsp </location> </error-page>
4. <error-page> <exception-type> mypackage.MyException</exception-type> </error-page>
5. <error-page> <servlet-name> myservlet</servlet-name> <exception-type> mypackage.MyException</exception-type> </error-page>
6. <exception> <servlet-name> myservlet</servlet-name> <exception-type> mypackage.MyException</exception-type> </exception>

Does this ask for the abilities for writing correct XML files, or does it ask for whether someone understands how to specify an error page in the deployment descriptor (web.xml) of a Java web application.

I think this confirms my concern that someone who is "certified" does not necessarily have to be an expert on the subject he/she has been certified.

My suggestion to an agile leader is therefore: Ignore the certifications and focus on the real output of your candidates. Use auditions, for example design sessions or pair programming, to assess the real skills of your candidates.

I don't believe that certifications will help you to determine whether a candidate has excellent social skills. And I also don't believe that this kind of questions helps to determine whether a candidate is able to find novel solutions.

At best the candidate can repeat previously learned canned answers. Is this what you are looking for?

Quote From Today's Scrum

I thought you'd like the following quote from a daily Scrum I attended today:

"If you click the add or delete button in a table, and nothing happens, something is wrong." (Author to remain unknown)

Two Hour Technical Task Too Much?

Our recruitment process includes a programming task, which we give candidates as a preparation for the first one hour interview. The task is typically very simple and it is possible to complete it within roughly two hours. The intention is to assess whether a candidate is a) able to solve a simple task independently, b) able to demonstrate know of how to ensure quality (e.g. automated tests), and c) willing to invest that time for joining a team of highly skilled people.

In over 100 applications in the recent months we have never had any complaint by the candidates. Instead we see good results with regards to the performance of the successful candidates.

However, there was one case where a candidate sent an almost "rude" response after he received the programming task:

"IMHO only a fool will spend 2 hours sitting for a technical test without the employer having gone through some trouble to have a pre-selection round first."

And later he added

"I happen to be not only adept on the technical front, but also socially observant and capable of making (mostly correct) strategic decision."

Do we expect too much? I know of several other companies who use technical tasks for engineering positions as well, for example ThoughtWorks.

In this particular case we decided to not invite the candidate based on him not being willing to comply with some simple rules which are part of the policy of our company.

I wonder who else is using technical tasks as part of the recruitment process. It would be great if you would be willing to share your experiences.

Customers Writing Executable Specifications

About two years ago I worked with a team which had to live (or suffer?) from requirements specifications with hundreds of pages of prose. This kind of document is hard to read, understand, and maintain. If you want to change it, and your customer is external, you have to follow a change management process which typically includes exchanging and having drafted and approved even more documents.

Ideally, requirements would be written in a way that makes it easy for the development team to verify whether the system satisfies them. So why not making requirements executable? That way your team members can run them as often as needed, and they could stop immediately once the system passes those tests.

The way to go forward is therefore executable specifications, or story tests. The most prominent thought leader on this is probably Rick Mugridge, on whose web site you can also find further information.

One tool to create and maintain such customer tests is Fitnesse. It is available for many different languages.

The benefits are very compelling. You have a much tighter link between your customer (might also be a product manager) and your development team. Executable specifications are a means for improving communication. You also get a tool that reduces the gap between what your customer wants the system to do, and what the system really does.

From my experience, it's worth playing with this concept. It might turn out to be an excellent addition to your toolbox for agile project management.

APLN

The Agile Project Leadership Network is a non-profit organization which connects all leaders with an interest in agile techniques. I just joined it as I happened to be at the leadership summit, which took place during the Agile 2006 Conference in Minneapolis. I'm still amazed about the high caliber of the people I met. It is a lot of fun to exchange experiences. Despite having facilitated the transition of multiple R&D organizations sized 10 to 200 engineers to agile methodologies, there was so much (And I guess there is much more) that I learned during this conference and the leadership summit. Thank you to all the other attendees! You are great people!