This is the first in a series of interviews we are publishing with users of the beta product. Interested in being a part of a user interview? Comment below or email us.

Bertrand Vidal, Software Engineer at LTU Technologies

Please introduce yourself, your team, and what you’re working on.

LTU provides cutting-edge image recognition technologies and services to global companies and organizations such as Adidas, Kantar Media and Ipsos. LTU’s solutions are available on-demand with LTU Cloud or on an on-premise basis with LTU Enterprise Software. These patented image recognition solutions enable LTU’s clients to effectively manage their visual assets – internally and externally – and innovate by bringing their end-users truly innovative visual experiences. In an image-centric world, LTU’s expertise runs the image recognition gamut from visual search, visual data management, investigations and media monitoring, to e-commerce, brand intelligence, and mobile applications.

Our technical teams use KANBAN and continuous integration to maintain the high quality standard LTU is known for, and to avail of our small size to quickly react to change. The 7 developers and 2 product owners are spread across 3 differents cities in 2 time zones: Paris, Lyon, and New York.

How does your team use AgileZen, and why?

Each product has its own board and each board has its own workflow (different WIP limit, different phases, …). When a new cycle starts for one of our products and the content has been decided, the team and the product owner gather to split the cycle into Stories. We try to make them as small as possible and as precise as possible so anyone can start working. Then each team member is assigned a Story and from there the developer can customize the Story as needed. Some use Tasks, some others use Tags, we even allow to break them into smaller Stories if need be.

Since our development team is spread over 3 locations and 2 timezones, we needed an online board so everyone would know what was going on in the current cycle. Our CTO needed a tool to follow the evolution of the team’s work and AgileZen offers just that (e.g. Throughput, Lead Time, and so on). We also wanted to be able to move Stories around easily – to export data into other tools. Using the AgileZen API made that painless. The API and a lot of git aliases allowed us to make our work smoother and simpler. We can now create a new git branch and specify the id of a Story; this will move the card to the “Working” column and automatically assign the Story.

What challenges does your team face around collaboration?

Being spread over 2 timezones is probably the biggest issue since it sometimes slows down our work flow. Other challenges around collaboration have been answered by appropriate tools, including AgileZen.

How has your experience been with the beta version?

The team has been using the original product for almost 3 years now. Those of us who have been testing the beta version have only positive feedback. The 2 biggest improvements for us are the ability to better manage the Stories in the backlog, and the right Focus Panel describing a Story when selected. The backlog should now be considered as a seperate board made just for planning and the distinction between backlog and the board was very important to us. This makes the Story selecting and sorting process faster. The right side Focus Panel allows fast access to the Story details without leaving the board, making the Story management even smoother.

This is the first in a series of interviews we are publishing with users of the beta product. Interested in being a part of a user interview? Comment below or email us.

Sarel van der Walt, Software and Development Manager at Afrihost

Please introduce yourself, your team, and what you’re working on.

I’ve been developing software since primary school and have grown from Application Development to Web Development to Web Application Development and specialized in integrations between systems. Currently I’m the Software and Development Manager at Afrihost where I’ve been working for just under 6 years now. Our Dev Team is 8 souls strong, and are responsible for the internal and external systems related to the Afrihost products. The systems range from our Client Management Backend (back-office system), our billing engine, automated deployments of servers and services, and lastly but not least our Client Zone. Everything is web based and the background scripts are written in PHP (on top of Symfony Framework). Our team adheres to some variation and blend between SCRUM and KANBAN and some other stuff we learned along the years. Generally we try to react to market changes and new products within one workday. We pride ourselves that we can deploy a completely new product in way less time than our competitors, which made us the #1 privately owned ISP in South Africa, winning the “MyBroadband.co.za ISP Of the Year” two consecutive years in a row and we’re working hard for our third.

How does your team use AgileZen, and why?

Everything we do becomes a story in AgileZen, and we try as far as possible to put the steps in Tasks. The reason we picked AgileZen was simplicity and price. It takes a major time investment understanding and setting up many other products, where as with AgileZen it was a plug-and-play solution for us, we could merely add the members to it, and start using it. The most time we spent was customizing the columns, which was less than 30 minutes.

What challenges does your team face around collaboration?

A lot of times more than one person is assigned to a story, and it’s tough to then collaborate on the different parts of a story, so we’ve limped along with email subject naming conventions to create a thread of discussion about a user-story. Also, the sad truth is that a lot of times we just don’t have the time to collaborate on everything, so certain parts of the system is developed without the rest of the team knowing anything about it (or very little about it). We do, however, find that our stand-up meetings in the morning which we do always makes a huge difference.

What challenges does your team face around getting work done?

Interruptions are probably the biggest challenge. Unfortunately, with a high-speed business, that comes with the territory. Other than that we don’t have major problems. Sometimes projects do get put on hold, but that’s always when something that adds more value comes up, and we generally get back to the original project rather quickly.

Share one way that the beta has improved your team’s ability to collaborate and/or get work done.

The entire team has not been added to the Beta version yet, we have only evaluated the Beta to compare it to other mainstream products out there to make sure AgileZen is something we want to stick to, and at this time we’re happy (and happy with the beta) with what it gives us.

This is a guest post written by Andy Trainer of Silicon Beach Training

Effective communication is key to any successful relationship, not least within a project team. As a project manager – or any professional person in business – you need to really listen to what those around you are saying. Improving your listening skills means you are more likely to fully understand a situation – and will also earn you the respect of others.

Learning project management techniques such as PRINCE2 will give you the theory and resources to run successful projects. Similarly, becoming familiar with project management software such as AgileZen will support your project management efforts, and make your working life easier to manage.

It’s also important to keep up with ‘soft’ management skills such as the importance of active listening – they have a significant impact on the team and ultimately the success of the project.

After a day of meetings or during a hectic work schedule, you may find you tune out and find it hard to focus. These tips will not only help you take in all the information you are given, but ensure the speaker’s confidence in your attention and interest.

1. Body language is key. Turning to face the speaker will not only show them you’re listening but will make it easier for you to avoid distractions.
2. Speaking of which, do what you can to reduce potential distractions. Make sure both you and the speaker are turned away from your computers, that phones are on silent and out of reach, and that you aren’t likely to be interrupted. If it means moving to another room then so be it.
3. Hold eye contact. This should come naturally if you follow tips one and two, but is certainly worth being aware of the difference it can make to your listening skills and the confidence you instil in others.
4. Hold back your internal monologue and focus on what the speaker is saying. They may be listing problems that need to be addressed, but wait until they’ve finished before you start trying to come up with solutions. You may miss out on other important parts of what they are saying – and they may already have solutions to present to you later on.
5. Show active listening by responding to what they are saying – but don’t force it. Nodding, murmuring and making facial expressions are fine but don’t let coming up with appropriate responses become a distraction in itself!
6. If you have something to say in return, don’t interrupt. If it’s important then it will still be relevant when they finish.
7. Similarly, keep an open mind if your instinct is to disagree. You may find concerns are quelled if you keep on listening and, if not, you can always raise these when they’ve finished speaking.
8. A common trap to fall into is to interrupt with words of support or advice, e.g., you might feel the urge to share a tale of when you’ve experienced the same sort of situation. Hold back and only give advice when it’s asked for. It’s easily to offend people by accidentally implying they don’t know how to handle a situation.
9. Understand silences – and certainly don’t use any tiny pause to jump into the conversation. Some people use a short silence to collect their thoughts – it doesn’t necessarily mean they have finished, so give them a chance to continue.
10. When it’s your turn to speak, recap what they said with “so you’re saying…”. This shows you listened to everything they said – and that understanding them correctly is important to you.

— —

About the Author:

Andy Trainer works for Silicon Beach Training, leading providers of Project Management resources and courses, including PRINCE2.

I’m using the free version of AgileZen. The project I track is the development of a Windows Phone 7 app. We are 2 people working on this app. We were using Excel before AgileZen in order to track “tasks” to implement in our app – it was cumbersome and not flexible.

Now with AgileZen, we have the following categories:

• Backlog: default backlog
• Design: tasks which cannot be implemented because of a lack of UI design
• Decision: tasks which cannot be implemented and need to be discussed before to make a choice
• Ready: tasks ready to be implemented
• In Progress: tasks in progress
• Completed: tasks completed and ready for peer review (testing)
• Archive

This post was written by Kelly Taylor – @ktinboulder from PR Newswire

I am the Product Owner on a 10 person development team building tools to help  our PR, Marketing and Investor Relations Communicators teams find insights in the social web and traditional media then distribute their text or multimedia content to targeted audiences. We are using Ruby on Rails, jQuery, MongoDB and many APIs in our web applications.

Our team was using an enterprise ALM tool for a year which was wonderful for Product Owners and Executives as the user interface was very conducive to planning Sprints and Releases. Backlog management was great and Stories could be well elaborated. However, the development team hated using the tool and it was a constant source of frustration.

We decided to try AgileZen using a very minimalist approach and a commitment from the team to use the Kanban Board. Our team also uses Campfire, GitHub and Jenkins in our workflow and have leveraged APIs to post updates automatically to Campfire. The frustration ceased and we have never looked back.

Being part of an enterprise, we struggle with large team collaboration and consolidating portfolio roadmaps. We have leveraged AgileZen’s multiple boards feature to have high level portfolio planning boards for management as well as our day to day development team board. The ability for each team or group of stakeholders to define their own workflow for a board has been key to the success of AgileZen for us.

When your development team is empowered to use the tools that optimize their workflow, consistent delivery of quality software will follow.

I’m a project manager, and I use AgileZen to visualize my personal stories. Initially, I used the tool for my professional work, but after the reading of Personal Kanban, I use AgileZen to manage my personal work. Below is a screenshot of my board:

I use one board for both my personal and professional kanban work. The gray color is for my professional work, and the green is for my personal work. For me, the Performance screen is very valuable in seeing how I complete tasks. My workflow (and work-in-progress limits) are as follows:

Backlog – Stories that will be worked on someday
Ready (6) – Stories that are ready to be worked on
Today (4) – Stories to be done today
Working (8) – Stories that are currently being worked on
Hibernate (10) – Stories which are being worked on but can wait to be completed
Complete (6) – Stories that have been completed
Archive – Stories that are history

David Shrimpton (@davidjshrimpton) is the Custom Website Development Manager for the Global publisher John Wiley & Sons. He works with teams across the UK, Germany, Singapore and Moscow. David has over ten years experience in managing software teams, products and projects. The views expressed here are my own and not those of anyone I work for.

David Shrimpton

Trying to change the way you work is one of the hardest challenges companies or departments face.  With AgileZen and Kanban we have been able to visualise our workload, monitor our workflow and introduce changes that have revolutionised the way we work as a department. It has also highlighted changes that we need to make in other areas of the company.

Over the past 2 years we have been using AgileZen and Kanban to help us examine and visualise the way we work. It has been a complete game changer for us and that’s why we have signed up to AgileZen for another year.

So what are the advantages of using Kanban and using AgileZen in visualising work flow and limiting your work which eventually leads to greater productivity?

According to David J Anderson, a major Kanban thought leader (@agilemanager on Twitter), the process leads to:

• A smoother flow and greater agility
• Evolutionary change and less resistance
• Better predictability in controlling variability and eliminating over burdening
• Better risk management

Our Process
Within AgileZen we have a number of boards which we use in our development, personal and project process. We have two main development boards: one for our ASP and .Net development, the other for our Java development.

On each board we have project work and issues and we ask our Product Manager to select the next stories to be worked on by our development teams. We have two main types of cards, one for Issues and the other for Projects.

Smoother Flow
The advantage of AgileZen is that it helps us monitor our flow of cards moving from one side of the board to the other. We can see when items are not being pulled into the next column or blocked. We can then work to either free up resources to pull stories or swarm around blockers to make sure we resolve the issues.

AgileZen has helped us identify where we need to employ more resources to make sure we can continue pulling cards into columns at a steady rate.

With AgileZen you can see who wrote the story and who is in charge of it, whose working on the story at any stage and at which stage the story is within our development process.

We can also see where we need to look at our process and where things need discussing and changing.

Greater Agility
One of the main advantages of Kanban is that we can re-prioritize our next stories that the customer thinks are most important by changing them in the selected column before development analysis and work takes place. AgileZen makes it very simple and easy to do this by letting us pick up the card and drag or click to move into the next column.

With our process we have to be pragmatic so AgileZen lets us skip columns because our issues don’t go through the same process as our stories or MMF’s.

We can also monitor and change our process very easily. AgileZen provides us with monitoring tools and the ability to be able to move or change our columns with the click of our mouse.

Evolutionary Change – Less Resistance
With AgileZen you can monitor progress and then trial changes to improve the quality, delivery and length of time the product takes to be delivered. Because of the way AgileZen works it provides a visual reference and monitoring for where things are taking their time or when things are blocked and the reasons for that. It highlights problem areas which then you can look at with your teams and everybody knows where they are because everyone can see progress.

Better Predictability – Controlling Variability
AgileZen provides an easy way to measure how long a card takes to go from the selected column across the board into the archive. This lets us gauge how long small, medium or large stories may take to be delivered.

If we make a change then we can measure it over a period of time to see whether it has helped increase the quality of our products or the delivery time.

Better Predictability – Eliminate Over Burdening
When you first create your board within AgileZen you get to set your work in progress limits (WIP limits). By setting them low it means that the cards move faster through the board.

Within the AgileZen board you can see who is working on what story and if they have too much work and are themselves becoming a blocker. You can also see where you need to hire more staff to keep cards flowing through the board.

Better Risk Management
Because of the visual nature of Kanban we have the ability to not only monitor risks but also to collect data and diagnose long term issues which could then turn into risks for other software projects.

Conclusion
All of our Custom Sites team distributed teams across the world work with AgileZen and find it very easy to use. This tool is still one of the best and most simple one to use. This is why I would recommend all software teams to try Kanban and AgileZen and help change their process for the better.

If you have questions about how we’re using AgileZen, it would be great to hear from you in the comments.

Shawn Weisfeld, Lead Organizer of the Dallas GiveCamp, explains how AgileZen helps with organizing this amazing event. You can learn more at DallasGiveCamp.org.

Have you ever tried to manage over 100 developers across 13 development teams each working on a different project? Oh did I mention that these teams have never worked together, oh and they all only have 48 hours to complete their projects. Well this is an annual occurrence at the Dallas GiveCamp. Each year volunteers across the Dallas/Ft. Worth Metroplex volunteer their weekend as part of the National Day of GiveCamp to build websites for local charities. As you can imagine coordinating all of this is a massive undertaking. This year however many of the teams have had a bit of help, from AgileZen. Using AgileZen the project managers were able to quickly divide work up across each member of the team. Then at a glance they can see what tasks were falling behind schedule and quickly get those tasks moving again. Additionally it allowed the charity representatives to see how the project was progressing. Most of all it reduced the risk of tasks slipping through the cracks, with a 48 hour development window, there is no time for mistakes. All the folks at the Dallas GiveCamp would like to extend a big thank you to the Team at AgileZen for donating their services for our event and we look forward to working with them in the future.

A loyal AgileZen user, Christian Grobmeier, recently posted his Ten Rules of a Zen Programmer. Christian is a German developer, having built Time & Bill, a time tracking tool (available on the web and in the Android Market). Christian reached out and offered his thoughts on the AgileZen product and his programming philosophy. Below are some of his ideas that resonated particularly well with our approach at AgileZen:

I use a Kanban strategy (with AgileZen) and Time & Bill to focus. For me, both tools are the perfect combination. The only thing I can’t do with them is to keep distance from work – but well, that’s what I have real life Zen for. With Kanban it is possible for me to handle the giant number of daily tasks I perform. Currently, I spend my time writing books and technical articles, developing my own products, coding for customers, and much more. To work efficiently, I cannot have them all in my mind. Kanban lets me drag and drop the tasks to various states and help me to see what needs to be done. Sometimes I am so tired that I cannot think about the next task – it needs to be available when I need it.

Ten Rules
1. Focus
If you have decided to work on a task, do it as well as you can. Don’t start working on multiple things at the same time – do only one thing at one time. You’ll not become quicker, just you work multithreaded. If you work multithreaded you’ll become exhausted, make more errors and lose time jumping from one task to another. Similar to the Pomodoro technique, I plan a few time slots and concentrate on them. No chatting, no sleeping, no checking out a new great game on the Appstore.

2. Keep Your Mind Clean
Before you work on your software, you need to clean up your mind. Throw everything in it away for the time being. If the trouble is so heavy that you can’t let it go, don’t work. Try to clear things up, but when you start working, let the outer world melt away. Twitter, Facebook, and your email inbox are consuming much of your energy. Close them down.

3. Beginners Mind
Remember the days when you were a beginner (or memorize them if you still are one). Think of yourself as a beginner every day – you have never learned enough. Always try to see technologies from the perspective of a beginner.

4. No Ego
Some programmers have a huge problem: their own ego. Programmers with ego don’t learn. Learn from everybody, from the experienced and the newbies at the same time. As Kodo Sawaki once said, “You are not important.”

5. There is No Career Goal
There is a Zen saying: “A day without work is a day without food”. Hard work can be both fun and gratifying. There is no need to start searching for happiness after 20 years of work – you can be happy right now, even if you are not a Partner or don’t drive a Porsche. Never stay with a job that takes away the happiness in your life.

6. Shut Up
If you don’t have anything to say, don’t waste your colleague’s time. Every day you work, try not getting on someone’s nerves. Imagine if everybody would try this – what a great working place that would be? If you don’t develop an ego, it’s easy to support the ideas of others without forcing yours down their throat.

7. Mindfulness, Care, & Awareness
You are working, but at the same time you are living and breathing. Even when you have some hard times at work you need to listen to the signs of your body. You need to learn about the things which are good for you. This includes everything, including basic things like food and water. It is important to avoid working situations you don’t like – let go what doesn’t make you happy. “Care” is a huge word in Zen Buddhism – take care in every second of your life and your work.

8. There is No Boss
Yes, there is somebody who pays you. There is somebody who tells you what needs to be done. This is no reason to give up your own life or become burnt out on your work.

9. Do Something Else
A programmer is more than a programmer. You should do something which has nothing to do with computers. In your own time, do things you truly enjoy. A hobby is not just a hobby – it’s an expression of who you are. The things I have done outside of programming have made me the person I am now, and they have led me to Zen.

10. There is Nothing Special
A flower may be beautiful – but it’s just a beautiful flower, nothing more. There is nothing special about it. You are a human who can program. Maybe you are good at what you do. There is nothing special about you. Enjoy the colors and the smell of the flowers.

The only thing I can’t do with Time & Bill and AgileZen is to keep distance from work – but that’s what I have real life Zen for.

This post was originally published by Andy Schrader of Adzerk, an online ad network management tool, on Adzerk’s company blog.

We’ve been using Kanban for a couple of months now at Adzerk so I wanted to give you an update on how’s its been going.  spoiler alert: it’s great!

The Way We Were

As mentioned in previous posts, we’ve always used AgileZen to manage our backlog and current development work.  When it was just James, Kacy and I we could operate without too many rules/conventions. Mostly this meant that I snuck a ticket into the queue when James wasn’t looking and it was ignored in favor of shinier objects (don’t tell him I said that).

There were hundreds of tickets in the AgileZen backlog and we would meet regularly to pick which ones to work on next. Often a high priority would come up and get put directly into the working queue alongside existing tickets. It wasn’t uncommon for the queues to get fairly large until we had time to clean them up. Completed items would get moved to the ‘QA’ queue which would backup until we were ready for a deploy and then we would scramble to test everything before releasing into the wild. Unless you wanted to have some sort of roadmap, allow engineers to be laser focused on a small set of tickets and limit a bug’s impact on our customer base then it was all a glorious process that never failed.

A New Age

With the addition of Sarah and Jeffers (not to mention Andrew, Ron, Brian and Steve) we needed a bit more order to ensure we were focusing our resources on the right priorities.  In addition to better organizing our engineering team, we also needed a better way to give timelines to customers and market facing teams.  James gathered us all into a conference room and the Wild Wild West became the Renaissance.

AgileZen makes it easy to add Kanban limits to each step in the development process so we added limits to the number of tickets each queue could have. We moved forward with the following queues (and work-in-progress limits):

• Ready (7)
• UX (2)
• Working (4)
• Acceptance (4)

Only 7 tickets can be in the Ready queue and we limit the Acceptance queue to 4. The UX and Working queue limits are equal to the number of engineers+1. Somewhat arbitrary limits but there was also some thought put into them.

The key is to obey the Kanban work-in-progress limits and if the Kanban board is clogged you don’t want to continue moving tickets forward, which would be a Kanban violation. The first rule of Kanban is to follow Kanban, so when we catch someone violating the Kanban process by overloading a queue we play this ALERT throughout the office.

Effects of Kanban

From a product owner’s perspective this is all great because by instituting Kanban limits on each step the product owner has more control over what engineers focus on (he/she controls what goes into the ready queue). As the product owner I use Excel to manage the backlog of bugs/features and keep it prioritized at all times. When there’s room in the Ready queue I create a ticket and add it to AgileZen. When tickets are put into the Acceptance queue it’s the product owner’s responsibility to give final approval that a ticket is complete and works as intended. I get the last look at making sure it’s ready for customers to use and am responsible for clearing tickets off the board when they are complete.

Kanban encourages a team mentality because if any of the queues reach their limit the whole process gets clogged up which forces everyone to focus on fixing the clog. If there are already four tickets in the acceptance queue then no more tickets can get completed and moved into acceptance until the product owner clears out the queue. If there’s a problem testing a ticket because of the QA environment then it hurts everyone because the Kanban board gets backed up.

We’re constantly discussing the process and tweaking it to work better for us. If a ticket needs more work should we move it back to the working queue? We decided the answer is NO, tickets never move backwards (but I can see it working both ways). Do we need to have a UX queue? I’ll bet at some point we try getting rid of the UX queue and just have a Working queue with 5 or 6 slots. One new piece of the process for us was adding size attributes to each ticket so we can start tracking velocity. I’m excited about the new insights this will give us but I also expect it will also lead to some tweaks with our processes.

These were some big changes to adopt. And there was definitely some concern voiced when the Wild Wild West ended. “Rules!? We don’t need no stinking rules!!” The bottom line though is to not let the process get in the way of being productive. I think we’ve succeeded with that and everyone is much happier since the change.

TEASER

The best part about all of this, and I think everyone’s favorite part, is the use of feature flags. By using feature flags we’re able to continually deploy and keep new code hidden from production accounts. I’ll leave this topic for a future post but it’s a beautiful thing when combined with our Kanban process.