Monthly Archives: March 2016

Hundreds of Canadian employees from corporations, businesses and organizations are attending training to become Certified ScrumMasters and Certified Product Owners under the aegis of the Agile umbrella. From testimonials received from almost all attendees, they are enthusiastic about this training. As many have written, the training is helping them think beyond the status quo, and they are excited!

They return to their workplaces, report to their managers, talk amongst themselves – and then what happens? Nothing. Nothing changes. Their learning, their positive motives to enact change, their hopes slowly dissipate in the face of ignorance and apathy.

Where’s the disconnect?

It seems the disconnect belongs to the executives. CEO’s, VP’s, upper management have been avoiding a work revolution happening right under their noses. The revolution began in 1998 with the creation of the Agile framework, resulting in the Agile Manifesto, http://agilemanifesto.org, written in February of 2001 by seventeen independent software practitioners.

Not only has Agile transformed software creation, but it has been proven to be of value for all areas of business enterprises and organizations beyond software and IT departments.

Are executives remaining willfully ignorant of a twenty-first century framework for creating more fulfilling workplaces and delivering greater value to their customers? Or will Executives learn what is happening at the grassroots and make changes to fulfill the hopes of employees?

This is a call to action. It is time for executives to step up to the plate.

Real testimonials about training can be found at http://www.worldmindware.com/CertifiedScrumMaster

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

March 9, 2016, I took advantage of a free webinar offered by the Scrum Alliance, with the above title. We were told 5,000 people were attending! Angela Johnson’s presentation was based on information from both the Scrum and psychology communities.

First, she reiterated many ideas that are commonly understood about the role of a ScrumMaster (SM): an internal coach, a servant leader, an active facilitator. The SM makes sure that the rules of Scrum are followed by a team, but focuses on interactions and outcomes. As in football, the SM is truly a coach.

She described how new SM’s often latch onto the mechanics of Scrum, but most important are the personal interactions of a team. When difficulties arise, it is important to ask: “Do we have a Scrum problem, or is it a people problem?”

Ms. Johnson cited two resources available to SM’s to understand people interactions and problems better. One is the previous publication by Dale Carnegie called “How to Win Friends and Influence People.” The other is a newer resource by Michael James available online as scrummasterchecklist.org. In it James covers ideas like “How is my team doing?…How is the product owner doing?…etc”

She also cited a fascinating book by Harvey Robbins and Michael Finley called “’The New’ Why Teams Don’t Work.” She spoke about the importance of goals and objectives for a team. Bad Teams have vague goals and objectives. Good Teams may have clearer goals and engage in barrier identification. But the Best Teams have clear, short-term goals with continuous high-priority goals and objectives in segments of 30 days or less; they also identify barriers to people and processes. Best Teams ultimately value differences among team members, and develop something she called “versatility plans in interpersonal relationships.” (I wanted to learn more about this idea and posed a question in the webinar which unfortunately went unanswered.)

She then turned to psychology to discuss behavioral style differences in people. Four distinct personality types were explored: the Analytical (asks how?), the Driver (asks what?), the Amiable (asks who?) and the Expressive (asks why?). She believes a SM might help team members identify which personality quadrant they belong in so as to better understand each other. As well, in knowing the type of people who are in his/her team, a SM could adjust his/her communication and behavior to better reach each type.

I think it would be an interesting exercise for a team to go through personality types at least once. The exercise itself, besides creating deeper understanding, could also lead to some “aha” moments and laughter.

Johnson went through a checklist of Harvey Robbins’ rules for building trust in a team or group of people, and I will list them here:

have clear, consistent goals

be open, fair, and willing to listen

be decisive (meet the definition of Done)

support all other team members

give credit to team members when due

be sensitive to the needs of members

respect others’ opinions

empower team members to act

adopt a “we” mentality

take responsibility for team actions

She then added tips about supporting versatility: a) you can only create an environment that encourages self-motivation rather than motivate others directly; b) assist people to interpret what you say, i.e. “What I’m about to say is to help…etc;” c) don’t overlook a variety of orientations, whether they are cultural, or gender-based. She advised that we need to be aware that orientation is very important to consider as the teams we work with have a greater number of people whose first language is not English.

She spoke about Scrum teams working within larger organizations. If the goal of Scrum is to produce greater value more quickly, then a SM should never have his/her attention split between more than one team. The SM has to be a teacher inside of an organization, to help management understand best practices – the SM is really the coach for a team, the Product Owner and the organization. Old habits die hard, so educating takes time.

Don’t allow language to get in the way of this process. Don’t say: “That’s not Agile! That’s not Scrum! You’re doing it wrong!” Instead say, “When you say Agile, what do you mean?” or, “What is the problem we’re trying to solve?” A SM can always point out that we have a choice to work in the old way, or to try something new. We have an opportunity to improve the way we work.

Agile and Scrum, she emphasized, are not destinations – they are about continuous improvement.

This summarizes just some of the valuable ideas Angela Johnson presented.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

A common Scrum myth is that Scrum teams don’t keep documents. The many sticky notes on the wall of a scrum room can be anxiety-provoking to traditional suit-and-tie folks. Formal documentation is considered to be the hard product of real work. But the truth is two-fold.

First, Scrum teams do keep documents: The product backlog and the sprint backlog, which are two of Scrum’s artifacts, are key documents for a Scrum project. Each has a precise role in moving the scrum team from product conception to shippable increments. Different teams or organizations keep these artifacts in formats that suit them, but the point is that they do.

Second, it is not true that all formal documents are a faithful (or useful) reflection of work. More often than not, it is not clear what they’re for. Team members typically keep documents in the hundreds, outdated files are seldom deleted and clean versions are often mixed up with drafts. As with all clutter, the 80-20 rule applies rather well here: 20% of documents supports 80% of the work effort. So, 80% of formal documentation is in fact clutter.

Adopting Scrum will challenge organizations to focus on nothing other than completing deliverables of highest value to customers. This focus is in fact reflected by the few but super-useful documents that Scrum teams keep. But to move into this state of razor-sharp focus, we need a clutter-free environment. And while there are many forms of clutter on the job, documents are a big one. Why? Because the documents we keep and the way we use them reflect how well we understand our role. Much like a divinatory tool, the collection of documents you keep are very telling of how you do your work. Is there an orderly process as would be reflected by an orderly and well-organized set of a few focused documents? Or is it a firefighting role as would be reflected by a random set of documents contrived into folders?

Decluttering work documents compares rather precisely with decluttering photographs. Both clutter categories bring up very similar levels of emotional and intellectual charge as well as frustration with the sheer volume that needs to be processed and purged. And unlike the ease of throwing out something bulky like a broken chair or a dulled out piece of clothing, decluttering documents and photographs are very daunting tasks whose detail will bring anyone to tears.

Office documents are very much like a typical photo collection by enthusiastic parents: Several hundred photos of Maxi kicking ball, three dozen photos of the tenth birthday cake, one whole album of Auntie over for dinner, and so on. Photos will range from the incognito-fuzzy to the acceptably crisp. All are equal, however, and are kept in bulging pounds of photo albums or hard drives ranging in the terabytes – or both.

You can see the similarity with documents: Several hundred versions of the scorecard, three dozen presentations on the same topic, a few thousand archive files, and so on. ‘Fuzzy’ documents surely make up the majority. They include the many versions with corrections, inputs and errors, and the older versions to name just a few. The ‘crisper’ documents are typically the most recent ones and likely the ones shared with the VP. But these soon become ‘fuzzy’ as new versions are produced. The main issue with documents is knowing exactly what they’re for and how they support value-adding processes; a problem that doesn’t exist in a Scrum framework.

The main thread of comparison between photos and work documents is the degree of psychic severance that must take place in the mind in order to be capable of throwing out the useless lot. In truth, decluttering photographs is one of the hardest categories to tackle and does not happen until one has built a strong decluttering muscle with simpler categories like clothes, shoes, pots, pans and the like. Because photographs fall under the ‘sentimental’ umbrella, it takes much more than simply assessing functionality. Instead, it requires:

An assimilated understanding of how to declutter, which means having built the decluttering muscle with simpler categories of stuff and having the gut to make sharp decluttering decisions,

A willingness to look squarely at the past and contrast it with today, which basically means grieving and all the complex steps that alone involves, and

A decision about what will be taken into the future, which must be actively considered as opposed to simply assuming that it’s what remains after decluttering the unwanted.

Releasing the way we create, share and keep documents is tantamount to releasing the way we work. That’s why decluttering documents is loaded with anxiety about how the future modus operandi will look like. An additional consideration here is to do this before anything is archived because if all the old is just moved into an archive, no one will open it because everyone subconsciously knows of all the mold that’s growing in there. So better not postpone the pain and roll with the punches. Taking a sword at opening each and every single file and processing for keep-dump-or-change, takes a lot of gut and staying power. Our attachment to documents is quite entrenched but it must be severed for the sake of agility.

The result of genuinely decluttering photographs is astonishing. The grieving process can be very intense; not only are issues resolved and dropped but pieces of the past are recalled into the present and the spirit regains integrity. The past is forgiven and the remains of the day are a powerful collection of sharp moments that are very much alive. Photographs are no longer nostalgic snapshots of the past but evidence of an assimilated experience in effect today. And with that, something very special happens: Fewer and fewer photographs are taken as soaking up a moment becomes far more precious than clunking through photographing it. This vulnerability to the passing of time is a key ingredient for living life intelligently.

Can you draw the parallels with documents? We spend most of our days at work. So, let me invite you to start tackling your collection and see how your newfound awareness pours into every other area of your life.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

In just a few weeks we will be hosting Craig Larman here in Toronto as he facilitates the first-ever-in-Canada Certified Large Scale Scrum Practitioner training! Large Scale Scrum (LeSS) is about de-scaling. In simple terms, this is about using Scrum to make the best possible use of the creativity, problem-solving and innovation abilities of large numbers of people, rather than getting them stuck in bureaucracy and management overhead.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

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

The quality of our software systems depends on refactoring. In fact, I believe that the only way that an organization can avoid refactoring is by going out of business. Maybe I should explain that.

Refactor or Die

Every software system that we build is inside a dynamic environment. The organization(s) using the software are all in a state of constant change. The people using the software are also constantly changing. Due to this constant change, every software system needs to be adapted to the environment in which it is used. Most of the time, businesses think of this constant change in terms of new features and enhancements – the scope of functionality that a system can handle. Less commonly, businesses think of this change in terms of the obvious external qualities and attributes of the system such as performance or security. But almost never does an organization, from a business perspective, think of the invisible qualities of the software system such as simplicity and technical excellence.

What happens when the business does not recognize those invisible qualities? I’m sure almost every software developer reading this can answer this question easily: the system becomes “crufty”, hard to maintain, bug-prone, costly to change, maze-like, complex. Some people refer to this as legacy code or technical debt.

The longer this state is allowed to continue, the more it costs to add new features – the stuff that the business really cares about. It is pretty easy to see how this works – for someone who has a technical background. But for those without a technical background it can be hard to understand. Here is a little analogy to help out.

Imagine that you set up a system for giving allowance to your kids. In this system, every week your kids have to fill out a simple form that has their name, the amount that they are requesting, and their signature. After a few weeks of doing this, you realize that it would be helpful to have the date on the form. You do this so that you can enter their allowance payments in your personal bookkeeping records. Then you decide that you need to add a spot for you to counter-sign so that the paper becomes a legal record of the allowance payment. Then your kids want extra allowance for a special outing. So you add some things on the form to allow them to make these special requests. Your accountant tells you that some portions of your kids allowance might be good to track for tax purposes. So, the form gets expanded to have fields for the several different possible uses that are beneficial to your taxes. Your form is getting quite complex by this point. Your kids start making other requests like to be paid by cheque or direct-deposit instead of in cash or to be paid advances against future allowances. Every new situation adds complexity to the form. The form expands over multiple pages. Filling out the form weekly starts to take significant time for each child and for you to review them. You realize that in numerous places on the form it would be more efficient to ask for information in a different way, but you’re not sure if it will have tax implications, so you decide not to make the changes… yet. You decide you need your own checklist to make sure that the forms are being filled out correctly. A new tax law means that you could claim some refunds if you have some additional information… and it can be applied retroactively, so you ask your kids to help transcribe all the old versions of the form into the latest version. It takes three days, and there is lots of guess-work. Your allowance tracking forms have become a bureaucratic nightmare.

The forms and their handling is what software developers have to deal with on a daily basis – and the business usually doesn’t give time to do that simplification step. The difference is that in software development there are tools, techniques and skills that allow your developers to maintain a system so that it doesn’t get into that nightmare state.

For a more in-deth description of this process of systems gradually becoming more and more difficult to improve, please see these two excellent articles by Kane Mar:

Ultimately, a software system can become so crufty that it costs more to add features than the business benefit of adding those features. If the business has the capacity, it is usually at this point that the business makes a hard decision: let’s re-write the system from scratch.

I used the word “decision” in that last sentence. What are the other options in that decision? Ignoring the problem might be okay for a while longer: if the company is still getting benefit from the operation of the system, then this can go on for quite a while. Throwing more bodies at the system can seem to help for a bit, but there are rapidly diminishing returns on that approach (see The Mythical Man-Month for details). At some point, however, another threshold is reached: the cost of maintaining the operation of the system grows to the point where it is more expensive than the operational value of the system. Again, the business can make a hard decision, but it is in a worse place to do so: to replace the system (either by re-writing or buying a packaged solution), but without the operating margin to fund the replacement.

In his articles, Kane Mar describes this like so:

It’s pretty clear that a company in this situation has some difficult decisions ahead. There may be some temporary solution that would allow [a company] to use the existing system while building a new product, [A company] may decide to borrow money to fund the rewrite, or [a company] may want to consider returning any remaining value to their shareholders.

There are a few principles that are important in helping to answer these questions. All of these principles assume that we are talking about refactoring in an Agile team using a framework like Scrum, OpenAgile, or Kanban.

Refactoring Principle One: Keep It Small

Refactoring is safest and cheapest when it is done in many small increments rather than in large batches. The worst extreme is the complete system re-write refactoring. The best refactoring activities take seconds or minutes to execute. Small refactorings create a constant modest “overhead” in the work of the team. This overhead then becomes a natural part of the pace of the team.

Not all refactoring moves can be kept so small. For example, upgrading a component or module from a third party might show that your system has many dependencies on that module. In this case, efforts should be made to allow your system to use both the old and the new versions of the component simultaneously. This allows your system to be partially refactored. In other words, to break a large refactoring into many small refactorings. This, in turn, may force you to refactor your system to be more modular in its dependencies.

Another common problem with keeping refactorings small is the re-write problem. Your own system may have a major component that needs to be re-written. Again, finding creative technical means to allow for incremental refactoring of the component is crucial. This can often mean having temporary structures in your system to allow for the old and new parts to work harmoniously. One system that I was working on had to have two separate database platforms with some shared data in order to enable this “bi-modal” operation.

Refactoring Principle Two: Business Catalysts

When is the earliest that a refactoring should be done? Not whenever the technical team wants to do it. Instead, the technical team needs to use business requests as catalysts for refactoring. If the business needs a new feature, then refactoring should only be done on those parts of the system that are required to enable that feature. In other words, don’t refactor the whole user interface, just refactor the parts that relate to the specific business request.

Again, there can be exceptions to doing this… but only in the sense that some refactorings might be delayed until a later date. This is tricky: we want to make sure that we are not accumulating technical debt or creating legacy code. So, instead, we need to allow the technical team to refactor when they detect duplication. Duplication of code, data or structure in the system. A business request might impact a particular part of the system and the team sees how it might be necessary to refactor a large swath of the system as a result. But, the cost of doing so is not yet justified: the single request is not enough of a catalyst, and the team can also choose a simple temporary solution. Later, the business makes another request that also implies the same large refactoring. Now is the time to seriously consider it. It is now a question of duplication of another simple temporary solution. The business may not be happy with the extra expense of the large refactoring so the principle of keeping it small still applies. However, the technical team must also be willing to push back to the business under the right circumstances.

Refactoring Principle Three: Team Cohesion

Teamwork in Agile requires high levels of communication and collaboration. In refactoring work, teamwork applies just as much as in any other activity. Here, it is critical that all members of the team have a unified understanding of the principles and purpose of refactoring. But that is just the first level of team cohesion around refactoring.

The next level of team cohesion comes in the tools, techniques and practices that a team uses in refactoring. Examples include the unit testing frameworks, the mocking frameworks, the automation provided by development tools, continuous integration, and perhaps most importantly, the team working agreements about standard objectives of refactoring. This last idea is best expressed by the concept of refactoring to patterns.

The highest level of team cohesion in refactoring comes from collective code ownership and trust. Usually, this is built from practices such as pair programming or mob programming. These practices create deep levels of shared understanding among team members. This shared understanding leads to self-organizing behaviour in which team members make independent decisions that they know the other team members will support. It also impacts research and learning processes so that teams can do experiments and try alternatives quickly. All of which leads to the ability to do refactoring, large and small, quickly and without fear.

Refactoring Principle Four: Transparency

In many ways, this is the simplest refactoring principle: the team needs to be completely open and honest with all stakeholders about the cost of refactoring. This can be difficult at first. Another analogy helps to see the value of this. A surgeon does not hide the fact that care is put into creating a clean operating environment: washing hands, sterilizing instruments, wearing face masks and hair covers, restricted spaces, etc. In fact, all of those things contribute to the cost of surgery. A surgeon is a professional who has solid reasons for doing all those things and is open about the need for them. Likewise, software professionals need to be open about the costs of refactoring. This comes back to the main point of the first part of this article: hidden and deferred costs will still need to be paid… but with interest. Software professionals are up-front about the costs because doing so both minimizes the costs and gives stakeholders important information to make decisions.

The challenge for business stakeholders is to accept the costs. Respecting the team and trusting their decisions can sometimes be very hard. Teams sometimes make mistakes too, which complicates trust-building. The business stakeholders (for example, the Product Owner), must allow the team freedom to do refactoring. Ideally, it is continuous, small, and low-level. But once in a while, a team will have to do a large refactoring. How do you know if the cost is legitimate? Unfortunately, as a non-technical stakeholder, you can’t know with certainty. However, there are a few factors that can help you understand the cost and it’s legitimacy, namely, the principles that are described here.

If the refactoring is small, it is more likely to be legitimate.

If the refactoring is in response to a business catalyst, it is more likely to be legitimate.

If the refactoring is reflective of team cohesion, it is more likely to be legitimate.

And, of course, if the refactoring is made transparent, it is more likely to be legitimate.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

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 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:

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!

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

I’m going to be presenting a quick session on the use of a Skills Matrix to help launch a team. If you are in the Toronto area on the evening of March 16, come check it out: Agile TO Meetup.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.