Encouragement

How do you know your team is making progress? And how can you support them in doing so? I think it is not that hard.

One technique is to observe what they are doing and how they operate. Keep a log of your observations in particular of successes and to a lesser degree of the failures. Of course not in the sense of big brother. But more in the sense of helping people realize where they are coming from, what journey they have already behind them, what successes they had, etc.

A few weeks ago I noticed that one of my teams started to use a backlog for prioritization and planning and a burndown graph for tracking progress. Recently I observed the first stand-up meeting that took place in the team area instead of taking place in a meeting room with everybody sitting down.

It is successes like these, and acknowledging these, that helps people seeing things in perspective and understand how they are moving ahead. Encourage your team if you see positive things happening!

MindManager 8

I have written about MindManager before (here, here, here and here). A few months ago I finally took the step and tried out version 8. I never bothered installing version 7 let alone trying it out after I have received comments that other users had similar issues (in particular performance) in version 7 that I observed in versions 5 and 6.

Now here is the nice surprise: Finally the software is a useful tool from a performance perspective. And I don't have to switch off hardware acceleration.

And apparently some more work went into improving the tool. It has become easier to to selection the handles to modify the curves representing a relationship between two nodes. In previous versions it sometimes took selecting other elements, then selecting the relationship again to be able to hit the handle. It's not perfect yet but at least usable.

With regards to the performance I need to be more specific. The load time is now a little bit of an issue. I sometimes think for a moment whether I really want to close the program since starting takes quite some time. I'm not sure what it is doing, maybe counting each bit of my laptops memory? Once it's loaded working with maps is very smooth.

There are items in version 8, though, which would benefit from putting some more thoughts into them.

The Outlook addin doesn't seem to be up to it's job. After I installed it Outlook became very unstable. After I disabled the addin things went back to normal. So in the meantime I'm not using the Outlook addin. And quite frankly: I'm not missing it! What exactly were the benefits of the addin?

Another area worth considering is how call-outs can be placed in a map. Sometimes I wish I could place them further out on a map or close to the node that it is related to. However, if that node has many children and all are expanded the call-out has to be above or below all of them in terms of vertical position. That way the call-out ends up to be very far away. The layout algorithm should allow more freedom for call-outs.

So bottom line we are now looking at a product that has reached the maturity that as a leader you would expect from productivity tools. A few minor areas remain that MindJet should consider. But for now MindManager 8 is a very valuable piece of software and I use it on a daily basis.

Note: I'm not affiliated with MindJet or have any financial interest in the company or the product. The opinions expressed in this post are entirely my personal view and are not paid for.

Changing People's Mindset

One of the biggest challenges with building and fostering an agile team is to change people's mindset. It didn't take me long to realize that brain washing is not an option, although it is very tempting!

There are different approaches. One approach is to wait until a good opportunity comes up. For instance if there is a particular bug that was extremely painful and maybe somebody suggests to add one more step to the build process.

That's your signal! Ask what that additional step is and ask for more details. Then ask whether the additional step can be automated. And if the answer is 'yes', then ask to add the automation of that step to the build masters backlog. You don't have a build master? Well, then you have just identified yet another item that the team should put in place. You don't have a build master backlog yet? Well, there you go! Yet another opportunity.

So bottom line: This one single event can trigger the introduction of no less than three agile techniques: Automated Testing, Build Master, and Backlog.

The more I work with teams the less I see the need to push things out. Instead there are actually quite a lot of opportunities that present themselves. In other words: You don't have to wait long until such an opportunity is there. And then you can suggest the techniques that worked wonderfully in the past.

And by asking the right questions, again and again, including "How can we test this?" and "How can we automated this?" you drive your message home. Asking the same questions again and again will make sure that people start to change their minds. I have seen it more than once. Just keep insisting on answers to those two and similar questions. Be gentle but insist on those answers. It will pay off!

Introducing new tools

As a leader you may find yourself in the situation of having introduced a new tool. And then maybe you observe that the team doesn't know how to use it. The reason might be that they haven't yet fully understood the underlying principles and so if they hit a road block they might not be able to adapt.

Resist to the temptation of then doing the work for them. It's not worth it and doesn't scale. Instead work with the team and demonstrate to them how the tools is supposed to be used. Then give them another try encouraging them to come back to you for more assistance if they get stuck.

For instance: Assume you have introduced a spreadsheet based tracker (for an example see the Agile Tracker) including a backlog and a burn down graph. One way of introducing this could be to identify a significant portion of the work that is very similar and of which the items can be counted. The resulting backlog may not contain all the full piece of work required. Hence you and your team don't know yet whether the work can be completed on time. Ask them to include every single piece of work that is required. Ask them to prioritize - or if necessary triage - all tasks. If they struggle how to do that, use a few examples to demonstrate the use of the tool (the tracker in this case), then ask them to try the rest by themselves.

I believe this works better than if as a leader you would be involved all way through. Be available when needed. Make sure it is understood that asking for assistance is not a sign of weakness but a sign of strength. Briefly discuss their experience so far. What went wrong? What worked? Then provide just enough to get them going again.

Some Non-Cash 'Carrots'

Leadership sometimes requires finding a 'carrot' to make things happen. Not always does the 'carrot' need to be cash or other monetary items. Let me give you two examples.

In one case I worked with development team that wasn't keen to try pair programming. However, I observed that they were using pretty old computers for development and they were not happy with the performance.

Therefore I purchased a couple of high-end workstation, shiny, brand-new and fast, along with really nice large flat panel displays. I also got a desk for each of them so it would be easy for two people to sit next to each other on those desks. And finally I announced the rule that these boxes are dedicated to pair programming hence the powerful machines.

It didn't take long for the 'carrots' to show an effect. Slowly first but then more and more people tried it. Some only for a short time, some for more. And eventually I had to get more such machines and the team was totally hooked.

In a different case I was working with a team that was sitting on very old C++ code. The available tool set was appalling, and so I gave the team the direction to get onto Microsoft .NET, in particular C# where a much better tool set would be available, including good refactoring support, unit testing, and better libraries. And all the memory management crap would disappear as well.

Again it was close to impossible to get there. And some of the reasons given were just fine. For instance there were significant technical obstacles to make that shift easy.

Therefore I asked one of the team members to find out how to move the native C++ code to Managed C++. Sure, that wasn't straight forward either but it was an enabler and good step in the right direction. As a consequence it became much easier for the team to mix and match Managed C++ and C#. And since the tool support in C# was much better, more and more code was eventually written in C#.

These are just two cases where using an appropriate 'carrot' helped the team to move faster towards a desired outcome. Sure, in particular the second example is a bit special. Yet, I am sure that you are able to find more 'carrots' which work in your particular situation. I'd be interested in what you find out!