Tag Archives: transparency

The Perfect Agile Tool – 12 Key Features

Learn more about transforming people, process and culture with the Real Agility Program

The Perfect Agile Tool doesn’t yet exist.  In my training and consulting work, I often have strong words to say about electronic tools.  Most of the tools out there are really bad.  Unfortunately, JIRA, the most common tool, is also the worst that I know of.  (Actually, the only tool worse than JIRA for an Agile team is MS Project – which is just plain evil).  Some Agile tools do a bit better, but most fall far short of a good physical task board (information radiator).  I am often asked to evaluate and / or partner with tool vendors to “bless” their products.  Here is what I am looking for before I will consider an outright endorsement of such a tool.

Features for a Perfect Agile Tool

This list is roughly organized in order of features which do show up in some tools to those which I have never seen or heard of in tools.

1. Skeumorphism: Cards and Wall

The tool should display the current work of an Agile team in a way that is immediately recognizable as a set of note cards or PostIt’s on a physical wall.  This includes colours, sizes, etc.  Most people will type to enter data so fonts should be chosen to mimic hand-printed letters.  Every aspect of the display should remind people of the physical analogue of the tool.

2. Live Update

As team members are using the tool, all updates that they make should be visible as immediate updates to all the other team members including typing, moving cards around, etc.  There is no off-line mode for the tool.  In fact, if the tool is not receiving live updates, it should be clearly disabled so that the team member knows there is a problem with the information they have displayed.

3. Simple or No Access Control

Most Agile methods strongly de-emphaisize or even disallow traditional roles and encourage self-organizing teams.  This means that fine-grained access control to different features of the tool should be eschewed in favour of extremely simple access control: everyone can do anything with the tool.  (It actually helps if there is no “undo” feature, just like there’s no easy way to erase Sharpie written on a note card.)

4. Infinite Zoom In/Out

When you are using cards on a wall, it is easy to see the whole wall or to get up close and see even very fine details on a single note card.  Although it does not have to be literally infinite, the wide and tight zoom levels in the tool should be at least a few orders of magnitude difference.  As well, the zoom feature should be extremely easy to use, similar perhaps to the way that Google Maps functions.  Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.

5. Touch Device Compatible

This seems like a super-obvious feature in this day and age of tablets, smart phones and touch-screen laptops.  And it would take the cards on the wall metaphor just that extra little way.  But very few tools are actually easy to use on touch devices.  Dragging cards around and pinch to zoom are the obvious aspects of this feature.  But nice finger-drawing features would also be a big plus (see below)!

6. Size Limit on Cards

For techies, this one is extremely counter-intuitive: limit the amount of information that can be stored on a “card” by the size of the card.  It shouldn’t be possible to attach documents, screen shots, and tons of meta-data to a single card.  Agile methods encourage time-boxing (e.g. Sprints), work-boxing (e.g. Work-in-Process limits), and space-boxing (e.g. team rooms).  This principle of putting boundaries around an environment should apply to the information stored on a card.  Information-boxing forces us to be succinct and to prefer face-to-face communication over written communication.  Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.

7. Minimal Meta-Data

Information-boxing also applies to meta-data.  Cards should not be associated with users in the system.  Cards should not have lots of numerical information.   Cards should not have associations with other cards such as parent-child or container-contained.  Cards should not store “state” information except in extremely limited ways.  At most, the electronic tool could store a card ID, card creation and removal time-stamps, and an association with either an Agile team or a product or project.

8. Overlapping Cards

Almost every electronic tool for Agile teams puts cards in columns.  Get rid of the columns, and allow cards to overlap.  If there is any “modal” behaviour in the tool, it would be to allow a team member to select and view a small collection of cards by de-overlapping them temporarily.  Overlapping allows the creation of visually interesting and useful relationships between cards.  Cards can be used to demarcate columns or groupings without enforcing strict in/out membership in a process step.

9. Rotatable, Foldable, Rip-able Cards

Increase the fidelity of the metaphor with physical cards on a wall.  Rotation, folding and ripping are all useful idioms for creating distinct visual cues in physical cards.  For example, one team might rotate cards 45 degrees to indicate that work is blocked on that card.  Or another team might fold a dog-ear on a card to indicate it is in-progress.  Or another team might rip cards to show they are complete.  The flexibility of physical cards needs to be replicated in the electronic environment to allow a team to create its own visual idioms.  Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.

10. Easy Sketching on Cards… Including the Back

Cards should allow free-form drawing with colours and some basic diagramming shapes (e.g. circles, squares, lines).  Don’t make it a full diagramming canvas!  Instead, allow team members to easily sketch layouts, UML, or state diagrams, or even memory aides.  The back side of the card is often the best place for more “complex” sketches, but don’t let the zoom feature allow for arbitrarily detailed drawing.  Lines need a minimum thickness to prevent excessive information storage on the cards.

11. Handwriting Recognition

With Siri and other voice-recognition systems, isn’t it time we also built in handwriting recognition?  Allowing a team member to toggle between the handwriting view and the “OCR” view would often help with understanding.  Allow it to be bi-directional so that the tool can “write” in the style of each of the team members so that text entry can be keyboard or finger/stylus.

12. Sync Between Wall and Electronic Tool

This is the most interesting feature: allow a photo of cards on a wall to be intelligently mapped to cards in an electronic tool (including creating new cards) and for the electronic tool to easily print on physical note cards for placement on a wall.  There is all sorts of complexity to this feature including image recognition and a possible hardware requirement for a printer that can handle very small paper sizes (not common!)

Key Anti-Features

These are the features that many electronic tools implement as part of being “enterprise-ready”.  I’ll be brief on these points:

No Individual Tracking – the team matters, not who does what.

No Dependency Management – teams break dependencies, tools don’t manage dependencies.

No Time Tracking – bums in seats typing doesn’t matter: “the primary measure of progress is working software” (or whatever valuable thing the team is building) – from the Agile Manifesto.

No Actuals vs. Estimates – we’re all bad at predicting the future so don’t bother with trying to get better.

No Report Generation – managers and leaders should come and see real results and interact directly with the team (also, statistics lie).

No Integration Points – this is the worst of the anti-features since it is the one that leads to the most anti-agile creeping featuritis.  Remember: “Individuals and interactions [are valued] over processes and tools” – from the Agile Manifesto.

Evaluation of Common Agile Tools

I go from “Good” to “Bad” with two special categories that are discontinuous from the normal scale: “Ideal” and “Evil”.  I think of tools as falling somewhere on this scale, but I acknowledge that these tools are evolving products and this diagram may not reflect current reality.  The scale looks like this, with a few examples put on the scale:

Perfect Agile Tool evaluation scale with examples

Plea for the Perfect Agile Tool

I still hope that some day someone will build the perfect Agile tool.  I’ve seen many of the ideal features listed above in other innovative non-Agile tools.  For example, 3M made a PostIt® Plus tool for the iPhone that does some really cool stuff.  There’s other tools that do handwriting recognition, etc.  Putting it all together in a super-user-friendly package would really get me excited.

Let me know if you think you know of a tool that gets close to the ideal – I would be happy to check it out and provide feedback / commentary!

Please share!

An Evolution of the Scrum of Scrums

Learn more about transforming people, process and culture with the Real Agility Program

This is the story of how the Scrum of Scrums has evolved for a large program I’m helping out with at one of our clients.

Scrum of Scrum photo Continue reading An Evolution of the Scrum of Scrums

Please share!

Scaled Agile Framework: I Learned about ROAM

Learn more about transforming people, process and culture with the Real Agility Program

The SAFe SPC training last week taught me quite a few interesting and useful new things. In reviewing my class materials, I noticed this little acronym: ROAM.  The way it is used in the SAFe training is that it is a mechanism for categorizing risks that teams identify as they are doing release planning.  ROAM stands for Resolved, Owned, Accepted, Mitigated.  The members of an Agile team or Agile Release Train identify risks and collaborate to decide how to handle them.  These risks are then place on a visible grid that has each of the four categories marked.  In this way, the whole Agile Release Train and their various stakeholders can have an open discussion and shared understanding about the risks to the Program Increment that they are planning.  Cool!

Please share!

The Rules of Scrum: I share my obstacles (technical, tools, process, teamwork, personal) every Daily Scrum

Learn more about transforming people, process and culture with the Real Agility Program

The principles of openness and transparency include being able to be truthful about ways that you are struggling.  A Team Member must share their struggles with their Scrum Team and with the ScrumMaster so that the team, at least, knows your status.  Without that visibility, the Scrum Team may make decisions that are difficult or impossible to implement due to hidden obstacles.  At every Daily Scrum, each Team Member should think carefully about the challenges they are currently facing, and share those challenges.  The ScrumMaster cannot do a good job without that transparency since a core part of their work is to deal with obstacles.  If a Team Member fails to be open about obstacles, or fails to recognize something in their environment as an obstacle, this can slow the team in its progress towards becoming a high-performance team.  Obstacles that persist for a long period of time simply because they are not openly discussed can have a demoralizing effect on the team.  On the other hand, a team that creates full visibility into their obstacles can enlist the help of stakeholders, work together to overcome those obstacles, and systematically become better and better at doing their work.

Please share!

The Rules of Scrum: The Product Backlog is easily visible to every stakeholder (e.g. cards on a wall or an electronic tool with open access)

Learn more about transforming people, process and culture with the Real Agility Program

The Product Backlog is a constantly changing artifact, owned by the Product Owner. Stakeholders need real-time visibility into the current state of the Product.  Stakeholders should be able to discuss the state of the Product Backlog with the Product Owner at any time, make recommendations and requests.  Any change resulting from the request of any stakeholder(s) must be visible in real-time to all other stakeholders.  One of the greatest benefits of a highly visible Product Backlog is that it becomes a conversational space for key stakeholders and many others that are connected to or interested in the work of the Scrum team.  Of course, a visible Product Backlog also upholds the Scrum value of transparency which is essential for long-term success with Scrum.  What if my Product Backlog is not easily visible to every stakeholder?  Stakeholders will become disengaged from the work of the Scrum Team, and will forget to give support and/or offer insights into the work.  If the Product Backlog is managed in an electronic tool that requires people to login and/or go into a special space that has restricted access then they are much less likely to view it regularly.

Please share!

Aspects of Truthfulness

Learn more about transforming people, process and culture with the Real Agility Program

I had a fantastic discussion this weekend while on a road trip with my colleague David Parker.  We talked about the different aspects of Truthfulness.  This is what we came up with.


Are you perfectly honest?  Is every statement you make factually correct to the best of your knowledge?

Behaviors that are not honest include: hyperbole and exaggeration,  sarcasm, falsehoods, omissions.

Honesty is the quality most obviously associated with Truthfulness.


When you make a commitment, do you keep it?  Are your deeds an accurate reflection of your words and thoughts?

Behaviors that erode integrity include hypocrisy, unreliability, lateness.


When someone wants to know something can they find it out from you?  Can you provide simple proof of your words and deeds?

Behaviors that prevent transparency include stonewalling, passing the buck, verbal diarrhea, and the use of esoteric or inappropriate jargon.

Do you accept that the unexpected is natural?  Have you given up trying to control your environment?

Things that block serenity are anxiety and worry, reactionary anger, backstabbing, and manipulation.


Do you accept that others have wisdom, knowledge and experience that you don’t?  Can you admit both the possibility of being wrong, and the fact of being wrong?

There are many things that prevent the development of humility: taking offense from comments about yourself, your ideas or your actions, insisting on your way, vanity, boasting, and even ostentatious self-deprecation.

Please share!

8 Team Room Tips

Learn more about transforming people, process and culture with the Real Agility Program

Here are eight tips for making a great team room.

Light, Air, Nature
An appropriate amount of natural light, air circulation and live plants are excellent ways to make a space suitable for human occupation. The lack of these things can subtly but surely slow down and demoralize a team.

People need to be able to face each other and work beside each other. They also need a semi-private space to have discussions or make phone calls. The walls of the space need to have large areas that can be used for whiteboards.

It’s just not worth it to have a high-performance team hampered by a poor workstation setup. Good chairs, tables at an appropriate height, and the flexibility to allow individual ergonomic needs to be accommodated all help.

Every member of the team needs to be able to get away for short amounts of time. Some organizations provide separate mini conference rooms or “hoteling” spaces. Others allow staff to keep a private cubicle away from the team room.

The area of space that a person occupies needs to be flexible and personalized. People need pictures, toys, plants, and other incidentals to help them make a space their own.  For this, elbow room is important!

Visibility to Outsiders
Other people in the organization need to be able to walk by to see and hear what is going on with the Agile Work team. Open doors, windows or a “bullpen” formation of cubicles all allow this.

The space must be located so that washrooms, coffee, printers and other common services are easily accessible. It should not be set off and isolated far away from everything else.

The team will be noisy. Make sure that other people outside the team room are far enough away or isolated in some way from the noise. It can be hard to balance this with convenience and visibility.

Please share!