If you are using Trac and Scrum, you might have come to the point where you want to easily print ticket cards for your Scrum / Kanban board. At least, this is what happened to me. So, I created a little Java-tool to easily print Scrum / Kanban Ticket Cards.
It is available on Github:
There is some documentation in the wiki. Basically you may configure the tool in several ways:
- define, which field of the ticket will be displayed on the card
- define sizes, paddings, distances, …
It is possible to run the tool either as a stand-alone application or as a Java applet on your web-environment.
This is what a ticket card will look like: In my exampe, it shows the name of the sprint in the header area, the ticket number and summary in the content area below and some information about the reporter, owner and URL in Trac.
Maybe somebody finds it as useful as I do 🙂
As we started to do Scrum a couple of months ago on a project which was about to fail (and sadly did fail, but due to other reasons…), I came across the fact that there is huge potential to change the way we do things not just in project work but in our general daily work. At my company, we work in a great environment with really high-potential team members and a good social atmosphere. We are a small Online-Media & IT department under the roof of a medium sized newspaper publishing company. But even though we are less than 20 people, inert knowledge, intransparent descisions, unclear communication to stakeholders and a lack of knowledge about “who does what and what needs to be done” seem to result in a a re-active and dissatisfying way of work rather than a creative way of getting things done. So, I started to read blog articles and books about self-managed teams and agile development.
One book which in a particular way drawed my attention is Stephen Denning’s “The Leader’s Guide to Radical Management”. I am not a manager – as a software engineer I am part of a development team. Nevertheless, this book opened my eyes to what it really is that slows down development and maybe makes people unhappy about work in general – it is often a lack of transparency and responsibility to decide what is to be done in what time and what circumstances. Based on Dennings experience and talks to various managers across multible sectors in several countries, this is due to the fact that companies in the 21st century are still being managed in a traditional and unflexible 20th century way which major goal is rather delighting a client by providing quality services than making money and managing strictly top-down come whatever. Denning uses many stories and case studies to describe ways to achieve the goal of self-managed teams, establishing successful agile development and how to have an atmosphere of high performing work. This shall lead to better quality work and services, delighted clients and last but not least a happy work environment.
Even though I as a developer am not in the position to change things in a wide way across my company, this book gave me a lot of interesting thoughts and valuable information to change things in my surroundings – I’m really looking forward to start changing things in my office by “spreading the word” and trying to get people on board to move forward to a better organised, self-managed way to work. We already started by talking about it, establishing tools to centralise documentation and knowledge and thinking about better ways to handle incoming work in a transparent and productive way. There’s a lot you can do – Scrum is one method, Kanban another but this is all based on an uncompromising transparency, the will to enhance productivity or courage to admit failure and asking for help, which surely are some principles which really need to be learned from scratch – for both: “workers” and managers.
I really enjoyed reading the book and recommend it to everyone who wants to change the way things are done. For both – managers and workers – this book offers great opportunities to start changing things for better. Go and read 🙂