Scrum board. What's the best taskboard and information radiator?

About the last 10 years of my Agile experience I have been using various tools to monitor progress and keep an overview and radiate information. Some were more successful than others of course.
Some of the "best" products were not always helping. Now at Backbase we use a set of JIRA tools. Before that I used mainly Super Sticky Notes and a whiteboard. To keep track of the numbers and print a burndown I used a simple but effective spreadsheet and some counting on a daily basis to sum the work "done" and work "not done". Works great and is a good way to keep the taskboard up-to-date and clean. As a ScrumMaster I feel accountable for what's on the board.

Strawberries' Wall

For a bigger project and team we didn't have enough space for the sprints and whiteboards were not immediately available. We used a wall (Strawberries, red) as a taskboard and that worked also quite well.

Initially there was not too much trust that the notes would still be there after the cleaners came, or some non-project co-workers would make funny changes. All those imaginary "horror scenarios" didn't happen because the project was just too important to mess with. Sometimes an incorrect note was used (not a super sticky note), but was replaced by me then and I made sure we had only the right stickies around.

JIRA/Greenhopper

The JIRA/Greenhopper set works but I don't have the feeling to be in control and the tool is not easy as an information radiator. For stand-ups we used a laptop and beamer to have the actual taskboard available.

Doable but not my preferred way. As an information radiator you could use the Wallboard plugin/product but that requires an extra fixed display/TV/computer and I doubt a positive impact in the long run. It just becomes an expensive wall decoration is my guess. Nice to show off, but that's not what Scrum is about.

Homebrew tool

In the early days (in about 2002) for a project we built our own task management solution which was mainly a story/task management system to register the stories, the estimates, the remaining time and the percentage done. A very lightweight but usable webapp was the result after a couple of days development + thinking about it (<= 5 mandays using Java, yes that was no problem at all). The consequence was that for a few weeks it was used as intended but then the added value disappeared. We started to work in a mixed XP/RUP way and that worked very well. A number of use cases (with a focus on the happy day scenario's) was committed to by the team after estimation (in a story points like approach) and delivered a month later. Lot's of work was accomplished due to a fair amount of flexibility and negotiation space. This approach worked well with the small team. The lesson learned from this project was that building your own process supporting tool should be eliminated. It's never done and the process is more flexible than your homebrew tool. The positive aspect was that the team was thinking about how to make progress and manage that, before the project. That was absolutely worth a few days! The attitude to perform can't be bought, but can be created. We did that while not being consciously doing that. Looking back that's a nice lesson learned.

Pivotal tracker

During an other project I did in 2009, we used an early version of Pivotal Tracker (very stable and still free in those days). That was one of the easiest and -actually supporting- tools I used for Scrum. Just define your backlog, choose a sprint length, estimate your velocity and the tool helps you to do your sprints and project. That's the nutshell summary. I found it the easiest tool to use and we were able to import/export our stories (which is not always possible in other tools). And all kind of littele smart but very usefull features will be discovered in the first period of use. Great! From a information radiator perspective it's still not good enough for me. But for distributed teams I would say it's very recommended. I saw that they host public projects for free. I was very surprised by the number of public projects running and how active some are. If you have nothing to hide or keep secret, try it!

Conclusion

My conclusion is easy. Scrum is about openness and clarity. The physical boards helped me best to manage the progress and visibility was never an issue. In 5 minutes you can explain nearly everybody how the board works, easy. The openness of a physical taskboard gives a Product Owner or customer also confidence that the reports are based on actual progress.

So what's the good thing of having a taskboards with super sticky notes?

• Very visible
• Hiding work is hard
• Team peers see easy what's being worked on
• Updating is easy, add or remove a note or adjust the estimate
• Not closing Tasks and Stories is visible (no change on the board) and results in actions to solve that
• Closing Stories is very visible and gives team satisfaction (and PO/customer of course)
• I used Task notes and Story notes and wrote on all related ones the UserStory number/id. A Task without a number is clearly not 1:1 related to a UserStory (and not allowed)
• WIP/Work in progress can be limited easier due to visibility
• ... and more

If the team is distributed, things change. Then use a tool to support the distributed nature.

If the team is most of the time on the same location I managed it by sending pictures to the team members working remotely. Make sure you have a compact camera available which makes good readable pictures of a set of sticky notes. A smart phone could work but I have better experience with camera's.

Happy Scrumming!

<<

New job, blogging and mouse speed

It's been a long period since my last post with a lot of things that happened. So here is the short story.

I bought a new house last year and had to sell my own house. I'm glad that I was able to sell my house in time so that I'm not having double costs now. I even decided to sell it before our new house was ready... so we lived for about 4 months with my parents. That was fun with the four of us filling up my parents house (with them also there of course). That was in a normal, not too big, Dutch house.

The day before we got the key of our new house, an unexpected surprise came along. The financial situation of my employer was getting worse and they had to act unfortunately by cutting costs. I was one of the people that were "cut away" to make the future survival easier.

It was no fun to look for jobs during the summer season combined with a crisis still going on. But I did have quite a lot of interviews and finally one of my early interviews seemed to be the beginning of a new start.

I'm working now with pleasure at Backbase, the Next Generation Portal Software creator. A great product and a great company with much potential!

As a Manager Development I'll support the R&D teams to deliver great software and to improve the overall performance step by step.

Blogging has been tough the last 10 months, but I want to proceed again. From my various experiences and insights I want to write about Agile and Scrum, as a ScrumMaster, Manager and Agile Coach. My intention is to proceed with my blogging.

Mouse speed
While setting up my MacBook I wanted to speed up the tracking speed of my mouse. I like to use less desk space for my mouse to safe some energy and moves. Although I wanted to use the magic trackpad instead of the magic mouse, I didn't get it yet... Could it prevent RSI, I guess it will or at least makes you less RSI-receptive?

The magic mouse ain't bad! But the speed is too limited by the mouse settings in the System Preferences. By default there is a speed of max 3.

I found a solution (here) and that is to use a command line property changing the tracking speed. You can read the current speed and you can set (write) the new/wanted speed. The settings on the System Preferences|Mouse do not really adapt so a change there resets your speed back to the default tracking range (max 3).

So, use this to read the current value:

defaults read -g com.apple.mouse.scaling

Set the new value (I use 15 now):

defaults write -g com.apple.mouse.scaling 15

Be aware of logging out and in before the new setting are activated.

UPDATE (2011-12):
If this mouse speed thing is also one of your issues.... I ran into MagicPrefs which makes a lot of customizations possible for the magic mouse and trackpad. Maybe that's worth looking at.

Have fun!

2010: New and Improved (OneMonthProject)

Last month I wrote an article for the Whitehorses website. A Whitebook about a successful project (only in Dutch: Een succesvol project in de praktijk). The idea is that we approach projects in a new and improved way.

New about it is that we start building software after a very limited starting up phase. When we reach the moment that the customer wants to hire us and we can start, we form a mixed team and spend in total just a few days to get an understanding of what kind of system and what specific behaviour and requirements are expected.

Then we try to define the result we expect to reach and go live with after 1 calendar month. Then we start to reach the finish of the first month result as good and as fast as we can! It's sometimes hard to imagine that you can actually deliver working software after a few days or weeks, but we (we as the pro's in the IT industry) really can!

Ok. Then what's the improved part? The improved part is that we only want to fullfil the needs our customers needs. We focus on the functionality that helps out customers to do their jobs/services better and make money with it. Here is where we improve the way we work with the customer: we team up with the customer. Yes, the customer pays us. But we have to do the excellent job together!

That means, we are more intense involved with each other. Communication about what is wanted, what the priorities are, what makes money, what insights changed, etc will help to gain a better basis to reach the successful end results. Of course there is the risk of scope creep but we will also communicate about that of course. Here comes in the trust we require at both sides. The customer should be aware that moving and changing the target "while flying" costs time and money. We, the "result engineers", should help to keep the number of changes low by asking the right questions and make sure that we have the same target vision (results and business value). Together we do all this!

Some uncertainties in software development are still there. We approach the way we deliver software in a new and improved way but we can't eliminate all risks. The fact that we apply Continuous Integration, Automated Testing and a Testing Environment makes the time between running into and solving eventual risks short and thus a lot easier to mitigate. This applies on both the technical as the business issues.

After the first month we may be done or may just have delivered a piece of a bigger system. This type of months keep on repeating until we are not able to add enough value or the end result has been reached. Changing requirements in the future will normally be a set of various changes, approached by us in about the same way we did the project.

"One Month Project" is how we named this approach and will be offered to our clients from now (2010). Stock and capacity are limited but we plan to expand if we can or should.

There are lots of opportunities for customers to be done in about 1 month. We can help a customer to:

• build new business
• make efficiency steps;
• raise service levels;
• fix a problem;
• gain competitive advantage by making small (monthly) steps;
• make IT helpful (instead of blocking);
• innovate and excel;
• etc.

Lots of possibilities! And we really love to reach results. Our customer's business and success is our business.

I'll write more about this OneMonthProject appoach here, so if you like it: stay tuned.


Some info about the toolbox we use: agile, scrum, ruby on rails, java, jruby, linux, ruby, oracle, mysql, etc.

Performance and expectations

Although this post is rather short, I do write it.

At this very moment I'm waiting for a file-copy. I have an image of a virtual machine on an external USB drive (WB Passport Elite 250 GB, good drive!) and want to copy it to my fixed harddisk on my slow laptop (why are these things so slow within a year?). While waiting for it I'm able to write this. The expected time to finish was 16 minutes. So that is the time my laptop takes for copying a 16.081.982 kilobyte (about 15.4 GB?) file from an external disk to my internal laptop disk. Amazingly slow... it is about 1 GB/min = 16.5 MB/sec.

In the meantime it finished and it took 19 minutes and 12 seconds! Wow, that's a lot of time copying bits (so rougly 13.8 MB/sec. that's SSSSLLLOOOOWWW). And this is nearly an optimal situation because the file is one huge file. If it were a few thousand files it would probably have taken a something like 2 hours.

Why I started writing this? We all expect more than we easily get from technology. The new waves of technology are highly appreciated all the time until it has become a few months old or a commodity. But replacing things all the time can't be afforded by anyone, so we have to extend the use and lifetimes and make sure the investments are returned in the ratio we like it.

The link with what I do for a living is here! I want to start a few blogs related to projects, performance and expectations. I'm currently actively building up a "project offer" which helps in delivering projects very fast (max few months), providing good performance (in terms of speed of development and availability but also ROI) and fulfill and manage the too much underestimated expectations.

Later!

<

The Principle of ‘Results Beat All’

"The top strategy is ‘getting the stakeholder results’. Meeting requirements is more fundamental than any other process or principle."

The above text and principle comes from the writing of Tom Gilb. From his Competitive Engineering (CE) book. I'm kind of a fan of Tom Gilb. Since I got into touch with EVO, a "methodology" which could be seen as an early Agile approach of software engineering.

I just read the text because a tweet of him brought me to 100 CE principles, which are very valuable to "us". It triggered me because last week I had a tough dicussion with some people about the current status of a project.

In that discussion I was searching for the reasons of why the project still wasn't finished. The roughly expected date of delivery was about 3 months ago, but the end of the project is very hard to see and predict. I understand all excuses and reasons for not delivering yet but really can't understand that there is almost no understanding about having a HUGE problem.

I explained the team that we are not able to see any results now and that we expected to really SEE progress every sprint. The reaction was that a lot of progress has been made and that there is a lot of software that is of high quality, very flexible, future proof and now only the front-end has to be finished. And if I had taken the effort to look at the code and other non-functional artifacts, I could have SEEN progress (so it was "my own fault that I didn't see progress", WT*???). And of course, the expected date to deliver the system was unknown. No wonder we still have projects that never end or are way too late/expensive.

How can we become happy and build up trust if we don't meet the requirements? (the requested ones, with real value!). Having top-notch software without having delivered any requirements is worth nothing and therefor not really valued by the stakeholders. The top-notch quality software is normally implicitly expected.
The answers is of course to deliver the requested results by meeting the requirements. It is very simple but still not easy to get it done. And besides that, the progress transparency is adding trust. Show the progress made, the efforts it took and how long is still needed for delivering the remaining requirements agreed upon. Estimating may be hard initially, but try and improve...

The summary of this is that it's very wise to follow the basic rules and principles of proven approaches. I apply Scrum and will improve+adapt it where needed. But the basic goal doesn't change, deliver results ASAP!
The top strategy is ‘getting the stakeholder results’. Meeting requirements is more fundamental than any other process or principle.

Currently I'm working on a project approach to show and emphasize the focus on results. We expect to help customers with some short term need in one month!
When we start a project we need the global requirements and the required result. Together we create the product backlog and focus on the stories that make a system valuable and usable after ONE month! Of course not every project is completely done after one month but we are fully focussed on getting the stakeholder results available ASAP. Finishing, beautifying, fully integrating and extending the system afterwards is perfect common sense. But the value and results are there and our customer starts gaining from the added business value NEXT* month!


* if we are able to start NOW, we deliver NEXT month.

<

Microsoft Tag, that's what it is.

In my previous post I posted an image. That image is a tag. Tags are used worldwide for tagging, identifying and pricing articles and products. Now Microsoft created a new web oriented tag which in my opinion may become a huge success.

Read about it on the site of MS: http://www.microsoft.com/tag/

<

Find out what this is...

This picture can be machine read (even a mobile phone). But what is it?

About IT and business value

The crisis is a pain. In our business of IT-expertise consultancy weird things happen... The hourly rates are very much under pressure in a lot of cases. Even below cost price is seen...!? Is that because the business value of IT solutions is dropping (and the returns are lower than expected) or is it purely the crisis circumstance that costs are cut.

Both are probably true. But how would we solve that?

(We or) I focus on real business value delivered as soon as possible. Not waiting until the full solution is done, tested and approved. No, what can be delivered and result in actual business value, that must be delivered and used for business ASAP. And then we proceed with adding functionality that will even add more business value. And so on, until the added value will become lower than the costs. This mechanism gives ROI from an early moment and brings business and IT closer together. Narrowing or closing that gap between business and IT

Should IT be seen as costs? In a lot of organisations, IT is one of the bigger elements of the "general costs". But is that smart? In many situations IT is a requirements for the business and even the enabler or even the reason of competitive advantage. Is something that important a "cost"? Is it wise to cut that kind of costs?

Is IT not a main ingredient of normal modern business? Is it wise to increase that ingredient OR to lower it. I'm not talking about the costs but about the power of IT. IT can be applied very effective if you want, then it enables your business instead of being a high cost.

It's a matter of vision and the way we organize our business and it's value.

Become lean and agile and focus on value!

<

Getting to use GIT?

Git is a relative new player on the version control playground. A few years ago Git saw the light and was brought by one of the smart guys on this globe. Linus Torvalds; he needed a distributed version control tool to maintain the Linux kernel and seemed not to be too happy with the tool they used before Git. The exact story can be found somewhere else... (some links here)

I didn't use ALL of the possible version control systems but I guess I've seen about 6 or 7 different systems and all of them had pro's and cons, and from free+working to very expensive+not working. The latest I used was SVN and I thought it was OK. But now we start more to use some Ruby/Rails related tools and as a side-effect Git came by. The CI tool Integrity is the one we want to use and it seems to support Git out of the box but not SVN... Now what's wise to do?

I had a quick and global look at Git and created some repositories on Github and have to say it's easy to use... Of course things may change when I start to use the more advanced features but the basic use seems to be OK. So I'm able to make the step to Git!

And.. before I forget...
If you have some SVN repository and would like to try Git with your own stuff, Github provides a way to import your SVN repository. I also tried that and was glad to try some things out with some code I already knew...

BTW: a nice starter may be: http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github

SOA and complexity

SOA was the next generation of the modern solutions in IT, right? Yes it is, but why?

SOA is a rather vague architecture of how to create an very manageable, flexible infrastructure for all your current and future applications. But what's the SOA best practice. Ask the big SOA-package providers and they all offer a kind of similar story. It's always easy, connecting applications can be done in a snap and BPM and BAM will make life easier. If you create and follow the right plan and have a clear vision of the measurable goals, then you could get there. I really don't want to sound cynical, but bigger IT systems are complex [period]. And a SOA infrastructure may not pay off for the smaller IT systems. So SOA means complexity!

Complexity is not the same as "impossibly". Manageable complexity is what it's about. Enough cases do exist where the complexity may not be simplified. That's too bad, but make sure it's manageable! Unmanageable complexity results in unexpected problems, misuse and higher costs and may even create business risks.

Lowering the complexity starts with the awareness that SOA is a way to optimize your organization and therefore your business. SOA probably will not pay off if the business won't benefit from it.
(Of course enough people will try to use SOA as a technology replacer, but then the replacement will lower costs and provide new/extra features. I think that the business case will not benefit the business but may lower costs (especially when mutli-vendor middleware is being replaced). This happens of course, but that's not what my current blog story is about!)

So my advise... SOA is not a bad idea but is also not very new. The SOA term, terminology and current open standards provide never seen before integration possibilities (you remember CORBA?).
So.. At least think about the needs, the complexity, the manageability and make sure it's going to deliver value (preferably to the business).

Quiet, busy and holidays are waiting... and Ruby

Hi there, I haven't been around here for the last two months. I've had some great post-initiatives about SOA and related items but they are still unpublished. I didn't have the time to complete them.

Now I'm one day away from a holiday. I'll of course enjoy the free time without obligations but next to that I will improve my Ruby skills. Being a consultant/architect for nearly a decade I didn't really do any programming or development myself. But Ruby got my real attention more then a year ago and I'd like to be able to create solutions or applications in between my others tasks. Or for real (temporary) use.

One of the noticeable things is that Sun/Java is playing a bigger role in the Ruby world. Since about 2 years Sun hired a few smart guys to build a Ruby interpreter for the JVM/Java Virtual Machine (more info here). They already did a very great job but now I really believe in a nice Ruby future... Ruby on the JVM is about the fastest implementation around (see The Great Ruby Shootout, dec. 2008). We already knew that Java's performance is incredibly good, but as a platform for interpreted languages the JVM does a very good job again. So I'm very enthousiastic about JRuby.

Last year I did a Java + JRuby based project for Studielink (more). With a 2,5 man team (I was the 0,5 man ScrumMaster) we did a very good job within 2 months. About a year later I still have the feeling we out-performed ourselves. Thanks to a great team and great technology, we did the job. Even afterwards, sometimes a bug is found or a new small feature is requested. These are found, solved and deployed most of the time within one or a few hours after we started the task. That's what I call AgileMore!

The nature of that specific application enables direct deployment, I know and understand that is not always an option. But if it is, we can! Just like most successful internet initiatives, eg YouTube about daily adapted the features to provide more and better services and functionality continouosly.

Maybe I'll come up with some Ruby news the coming days/weeks. My blogging intention for 2009 is to post more regularly at least weekly. More Agile news, insight, SOA, etc. Hope to see you here!

Have a nice Christmas!

Use the current crisis to become agile and maybe make the SOA step

Now is the time to stop thinking about making a step to become agile and just do it. Why? It's simple, now is the time to improve your business, processes etc and make the steps that were desperately needed. Use the crisis to grow and become stronger and better then before and beat the competition now, they are struggeling now and thinking about how to survive.

Don't just cut costs. That won't make your business better. Focus on value, remove waste and remove blocking issues/obstacles. Cutting costs by cutting/decreasing staff may seem logical because a lot of costs are made there. But on the other hand, that's also where the value is created, for your clients. You want to serve your clients (and new ones) so try to provide more value instead of less, otherwise you may loose them and that requires making additional steps. Prevent the negative spiral and step into making progressive improvements...

Raise productivity, raise the quality... Deliver the best value, fast and for a very good price. But how? Go agile! Agile methods can cause changes in an organizations culture and positively change habits: everyone will adopt the idea of always delivering high value, high quality, quickly and keep always improving that. Those are the main goals of going agile. And how does that impact motivation... for free? The motivation should go up and may end in a super team, sometimes even hyper productive teams. Who doesn't want to have that?

Besides becoming better, it's a perfect way for customers to control spendings. Especially in the software development and delivery business, it's possible to deliver iteratively. Delivering high quality and quickly.... that will also improve the relationship between IT and business staff which gives additional opportunities.

Talking about opportunities... implementing and effectively utilizing SOA is one of them!

I looked at SOA from different perspectives. One of them is to create agility. With agility I mean that the business and organization are able to react and/or change within weeks/months instead of quarters/years (of course everything is relative, but I'm not talking about huge airplanes or rockets. It's about "very competitive" versus "too slow"). Suppose a customer has a request which fits your business perfectly but you're not able to provide the service/product right now. And suppose you think you should be able to... How long would it take to be able to actually deliver a high quality and fitting service/product? When you're agile it takes you something in the order of weeks/months to deliver the first potential shippable product(s) or service(s), not longer. SOA in this case facilitates in (re)useable services and infrastructure, so you're easily a few steps ahead of traditional practices, "out of your SOA box"!

One of the other perspectives is about fitness. IT fitness to be specific. SOA could help to improve your architecture and makes your IT fitter. Most bigger companies have an architecture which needs fixing. But the advise in most cases is: keep the hands off, you can't fix it. Theses types of architecture are too complex and ill-planned. SOA implementation could start from any point and that means making your IT fitter from the start. A fit IT architecture nowadays is really a requirement to become agile. Removing waste and obstacles is an activity here before (more) value can be created. Implementing a SOA requires that you should remove waste and obstacles, otherwise SOA may only add costs instead of resulting in a positve ROI.

No wonder... Agile and SOA seem to be very related. If you do it the right way and that seems not very easy, as most bigger and smart initiatives aren't! My message of this blog to you: choose to improve your organisation by becoming agile and think about combining that with a SOA. Instead of cutting costs...

Beat the crisis! Agile and SOA help you!

Timeboxing is bad? NO, it's GOOD!

Last week I read an article in the Computable (a Dutch IT week magazine, in Dutch only, sorry). The subject was about system design and which pitfalls should be prevented. Besides being a story about more or less well-known practices it ended with an statement that we shouldn't time box. It even says that the "time box promise" requires a iron discipline to first create the full design upfront.

The provided advise is exactly where the trouble started in the first place, that's why too much projects failed and still fail. That's why we love and apply Agile!

Agile iterative time boxes help us to focus and to deliver the required value/functionality which can be delivered in the time boxes and with the requested quality! I we fail, we really want to fail fast! Failing fast enables us to learn quickly from our mistakes and errors. Sticking to old "unproven" practices as the article suggests is not what I did and will do...

The funny thing was that two pages further, an article dedicated to agile practices was printed. It was an interview with/some citations of Alistair Cockburn. Communication, having a feedback-cycle and delivering the value in steps were the mentioned key values.

A nice anecdote in the article was that some project owner was very happy because he got exactly what he needed, not what he asked for in the first place. Suppose that happens very frequently... I know it does!

What is the wasted investment of a full upfront design? We will never know exactly, but we know that things change in our world and even just by thinking about the thing we want. And then I'm not even talking about complexity...

The article: Vermijd valkuilen bij systeemontwerp (English translation by Google)

Hug a developer today

Below is a nice video I found on the net which tells us a nice little story about the pain "we" have too much. Have a look at it, it only takes 90 seconds.

In my next posts I'll address this kind of issues and possible ways to prevent the pain.


(this video was created by DevShop)

Starting my blog

Soon (September) I'll start my regularly updated blog related to Agile and Lean principles applied to software and business development.

It's interesting to see that old habits and mechanisms that are not the most efficient nowadays are kept being used or applied a lot. Since my professional experience I've seen and applied a lot of alternatives and strongly believe and surely experienced that Agile/Lean principles actually result in better results and at the same time motivate the people and business involved.

These two factors -better results and motivated people and business- combined make both even stronger, so I've choosen and keep on going for that!