Tag Archives: features

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!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Technical Push-Back – When is it Okay? When is it Bad?

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

Whenever I run a Certified Scrum Product Owner training session, one concept stands out as critical for participants: the relationship of the Product Owner to the technical demands of the work being done by the Scrum team.

The Product Owner is responsible for prioritizing the Product Backlog. This responsibility is, of course, also matched by their authority to do so. When the Product Owner collaborates with the team in the process of prioritization, there may be ways which the team “pushes back”. There are two possible reasons for push-back. One is good, one is bad.

Bad Technical Push-Back

BudapestDSCN3928-smallThe team may look at a product backlog item or a user story and say “O gosh! There’s a lot there to think about! We have to build this fully-architected infrastructure before we can implement that story.” This is old waterfall thinking. It is bad. The team should always be thinking (and doing) YAGNI and KISS. Technical challenges should be solved in the simplest responsible way. Features should be implemented with the simplest technical solution that actually works.

As a Product Owner, one technique that you can use to help teams with this is that when the team asks questions, that you aggressively keep the user story as simple as possible. The questions that are asked may lead to the creation of new stories, or splitting the existing story. Here is an example…

Suppose the story is “As a job seeker I can post my resume to the web site…” If the technical team makes certain assumptions, they may create a complex system that allows resumes to be uploaded in multiple formats with automatic keyword extraction, and even beyond that, they may anticipate that the code needs to be ready for edge cases like WordPerfect format.  The technical team might also assume that the system needs a database schema that includes users, login credentials, one-to-many relationships with resumes, detailed structures about jobs, organizations, positions, dates, educational institutions, etc. The team might insist that creating a login screen in the UI is an essential prerequisite to allowing a user to upload their resume.  And as for business logic, they might decide that in order to implement all this, they need some sort of standard intermediate XML format that all resumes will be translated into so that searching features are easier to implement in the future.

It’s all CRAP, bloat and gold-plating.

Because that’s not what the Product Owner asked for.  The thing that’s really difficult for a team of techies to get with Scrum is that software is to be built incrementally.  The very first feature built is built in the simplest responsible way without assuming anything about future features.  In other words, build it like it is the last feature you will build, not the first.  In the Agile Manifesto this is described as:

Simplicity, the art of maximizing the amount of work not done, is essential.

The second feature the team builds should only add exactly what the Product Owner asks for.  Again, as if it was going to be the last feature built.  Every single feature (User Story / Product Backlog Item) is treated the same way.  Whenever the team starts to anticipate the business in any of these three ways, the team is wrong:

  1. Building a feature because the team thinks the Product Owner will want it.
  2. Building a feature because the Product Owner has put it later on the Product Backlog.
  3. Building a technical aspect of the system to support either of the first types of anticipation, even if the team doesn’t actually build the feature they are anticipating.

Okay, but what about architecture?  Fire your architects.  No kidding.¹

Good Technical Push-Back

Rube Goldberg Self Operating Napkin

Sometimes stuff gets non-simple: complicated, messy, hard to understand, hard to change.  This happens despite us techies all being super-smart.  Sometimes, in order to implement a new feature, we have to clean up what is already there.  The Product Owner might ask the Scrum Team to build this Product Backlog Item next and the team says something like: “yes, but it will take twice as long as we initially estimated, because we have to clean things up.”  This can be greatly disappointing for the Product Owner.  But, this is actually the kind of push-back a Product Owner wants.  Why?  In order to avoid destroying your business!  (Yup, that serious.)

This is called “Refactoring” and it is one of the critical Agile Engineering practices.  Martin Fowler wrote a great book about this about 15 years ago.  Refactoring is, simply, improving the design of your system without changing it’s business behaviour.  A simple example is changing a set of 3 radio buttons in the UI to a drop-down box with 3 options… so that later, the Product Owner can add 27 more options.  Refactoring at the level of code is often described as removing duplication.  But some types of refactoring are large: replacing a relational database with a NoSQL database, moving from Java to Python for a significant component of your system, doing a full UX re-design on your web application.  All of these are changes to the technical attributes of your system that are driven by an immediate need to add a new feature (or feature set) that is not supported by the current technology.

The Product Owner has asked for a new feature, now, and the team has decided that in order to build it, the existing system needs refactoring.  To be clear: the team is not anticipating that the Product Owner wants some feature in the future; it’s the very next feature that the team needs to build.

This all relates to another two principles from the Agile Manifesto:

Continuous attention to technical excellence and good design enhances agility.

and

The best architectures, requirements, and designs emerge from self-organizing teams.

In this case, the responsibilities of the team for technical excellence and creating the best system possible override the short-term (and short-sighted) desire of the business to trade off quality in order to get speed.  That trade-off always bites you in the end!  Why? Because of the cost of fixing quality problems increases exponentially as time passes from when they were introduced.

Young Girl Wiping Face With Napkin

 

 

 

 

 

 

 

Refactoring is not a bad word.

Keep your code clean.

Let your team keep its code clean.

Oh.  And fire your architects.

Update Sep. 8, 2015: Check out this YouTube video on the closely related topic of who has authority over the Product Backlog and why developers should not set the order of PBIs:

¹ I used to be a senior architect reporting directly to the CTO of Charles Schwab.  Effectively, I fired myself and launched an incredibly successful enterprise architecture re-write project… with no up-front architecture plan.  Really… fire your architects.  Everything they do is pure waste and overhead.  Someday I’ll write that article 🙂


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail