Virtual Agile

Cross posted from Atlassian Developer Blog

Index Cards have become an indispensable tool for a software development team practicing agile. There are a host of good sites with information on strategies for and benefits of utilizing index cards.

Agile teams use Index Cards for a variety of reasons, including:

• helping with iteration planning
• assigning tasks and then tracking developer assignments
• recording task estimates
• as one component of the team's Information Radiator.
• reminders of the conversations between customers and developers around the definition of user stories.

The cards are an excellent visual representation of the health of the iteration. A majority of cards still in the "to do" with the end of an iteration pending usually means the team is behind schedule. A scarcity of cards means the developers will soon run out of tasks and so the backlog had better be up to date. Cards also work well as a great tool for facilitating the assigning of work (more specifically, allowing developers to assign themselves individual tasks). On the JIRA Studio team at Atlassian, back in "Ye Olden Days" (circa 2008) we used to use actual physical index cards, stuck to the team white board with blu tack. The use of physical index cards does have drawbacks:

• Duplication of effort
• Data from cards and issue tracker being out of synch
• Bad handwriting leading to incorrect implementations
• Tons of old index cards lying around

We now use virtual index cards, thanks to the magic of Greenhopper, an agile planning tool that is now bundled free with JIRA Studio: 

Greenhopper is key to being able to do agile project management. We use the virtual cards for the traditional tasks of iteration planning, capturing requirements, and capturing acceptance criteria. The use of virtual cards allows for all of the functionality and advantages of physical cards, with the added advantage of better communication, and instant updates. Developers still "pick" their cards off the task board, track work on the cards, and place them in the "done" column when complete.

The JIRA Studio team was not a distributed team when we made the change to using the Greenhopper plugin exclusively. But now that one member is on another continent, the benefit of virtual cards to help with communication has grown even greater. Our Information Radiator is created with the virtual card wall displayed on a large monitor which also shows the current build status. Everyone on the local team can glance at the monitor for a visual representation of the health of the build and of the iteration, while the remote team member can view the exact same information in his web browser.

The synchronization of data is by far and away the biggest advantage of virtual cards, as an instant update of all information occurs whenever a card is updated. No more does a task get ignored due to a stray mark on the card. No longer does a developer waste time entering the same data onto the card and into JIRA. And the Team Lead no longer spends 30 minutes transcribing cards into JIRA issues or copying JIRA tasks onto cards in his chicken-scratch handwriting.

Greenhopper is integrated with JIRA Studio (and available as a plug-in for JIRA), so changes to a card are reflected in the JIRA issue, and vice versa. Moving the card to a new iteration, or new column on the board is reflected in the JIRA Issue. Changing the JIRA issue status to Assigned or Resolved immediately moves the card into the correct column on the Information Radiator. Almost as valuable is the ability to have multiple views of the information, without having to continually move physical cards. The cards can be viewed as a task board or a planning board, and sorted by priority, assignee, or a host of metrics.

Last, but definitely not least, the use of virtual cards mitigates a few of the dangers of agile.

Atlassian Starter Licenses: $5 JIRA and $5 Confluence

Atlassian is currently selling one year 5-seat JIRA and 5-seat Confluence licenses for $5 each - www.atlassian.com/starter. Offer is good for this week only. All proceeds go to the very worthy charity (Room to Read).

These instances are fully functional and supported instances of JIRA and Confluence, not "light" versions. They are renewable for $5 (all proceeds for renewals go to charity also) year after year.

Self Organizing teams.

It seems like kitchen based analogies are all the rage these days. In the interest in cashing in on this phenomenon I will relate watching Top Chef (Season 5, Restaurant Wars) with running self-organizing teams. Radhika was the "Chef/Owner" and took self organizing teams to its extreme level. Every chef on her team was allowed to do what ever they wanted, picking what ever assignments they wanted (regardless of who was best suited for which task), and she provided no guidance during the preparation of the meal. Regardless of how talented the individual team members were, not have any structure proved the downfall. And the food was really well prepared, but it was not enough.

Self organizing teams does not mean that a Team Lead can "Manage by being a lazy bastard" It still takes work. As tempting as it is to translate "allow developers to do the job as they see fit" into "I can go to the beach while developers do the work" if you do, you are done.

Mobius Strip of Priorities

It is no great secret that one of the great productivity killers in software development is context switching. Development by its very nature is a concentration driven activity. Forcing developers to modify what tasks they are working on before those tasks are complete causes it to take an order of magnitude more time to finally finish any given task.

A sure-fire way to keep developers engaged in a lot of context switching is to have constantly shifting priorities. Worse still is creating a set of priorities which does not establish a clear priority. I have seen several organizations create a Mobius Strip of Priorities, which pretty much guarantees that no clear direction is given to development teams.

The Mobius Strip of Priorities is one where the priority of project A is higher than project B, and project B is more important than project C, and of course, project C is far more important than project A. It can be very subtle, with several dozens tasks on the team plate, each with different stakeholders and advocates. There can be different criteria for priority, with product managers wanting quick wins, while VPs are wanting grand projects. It can sneak up on the unsuspecting team, and before you know it, you are following the Mobius strip around and around, looking for the edge so you can start coding.

It is the responsibility of the Team Lead/Manager to control this. Unfortunately, It is not simply a case where you can use the very effective tool of saying "no" to context switching After all, which project do you say no to? After all, each project is the highest priority. The key to preventing this, as simplistic as it sounds, is communication combined with actual decision making. Work with product managers and verify the priority list establishes priority. Spend time communicating with all the stake holders, so everyone is aware of the full picture, and can make informed decisions (one would hope they would make intelligent decisions too, but that is the subject of another post.) Don't let your developers founder in the Mobius Strip, establish the priorities clearly.

Annual Reviews - Final Thoughts

In talking with several people around the office about the low value of giving ratings during performance reviews, I realized there was yet another reasons they suck. Aside from the previous stated reasons of setting false expectations, they also focus employees self-improvement efforts into the wrong areas.

I think that a good leader encourages the most productivity from a team by planning and guiding work around each individual's strength. If you assign the quiet introspective super coder in the corner the job of external team communications, you are setting him/her, the team, and the project up for failure.

What does this have to do with ratings? Glad you asked. If you give a person any rating less than the highest, he/she will usually focus their efforts on improving the areas where they were the weakest. The mental calculus is simple - (Rating of GREAT + Rating of IMPROVE)/Overall Average Rating = Rating of GOOD. So they want to change the IMPROVE so that the resulting equation evaluates to GREAT.

But this doesn't help the individual, the team or the project. If they area needed to improve is drastic, then yes changes need to be made. But if the super coder starts spending his/her time trying to take on the persona of social hub rather than cranking out awesome code, then the manager has failed to get the most out of the team.

Responsibility

Who is responsible for the career development of employees? First and foremost of course, is the employees themselves. They know better than any manager their own goals, aspirations, motivations, and the hundreds of small details that factor into career decisions. They should be willing to communicate with their boss (who must be approachable, especially concerning topics this personal) about where they are, where they are going, and when and how they think they should be getting there.

However, it is also vitally important for a manager to be looking out for his team. For me, it is one of the most rewarding, and most profound, responsibilities, to have that much influence over someone's career and livelihood. It borders on managerial negligence to abdicate the responsibility of career development solely to the employee. A good manager will know what motivates individual team members, have a good general idea of the individuals personnel status (ready for promotion/raise/added responsibility) as well that individual's ability to handle any of the above.

Finally, a company's Human Resources/Personnel/Talent section should also be involved in ensuring that managers have all the information that they need to make informed and timely decisions. They should act as a safety net, double checking that managers have past performance reviews, pay data, market data, title and job descriptions for all employees as well as the title and job description for the next promotion level of all their employees. It does not matter that no one may be ready for a promotion or a raise, the managers need that information to do their job correctly, completely, and competently. Yes, it can be quite the workload to get and distribute all the necessary information, however it is well worth the effort. It is one of the main reasons a Talent organization exists within a company. A good manager and good Personnel personnel will work together towards ensuring no one slips through the organizational cracks.

Performance Reviews – part II.

Doing performance reviews are expensive, in both time and opportunity cost. So if you are going to do them, remember that the most important factor in designing a performance review system is to understand the objective you are trying to accomplish. If it is to rank employees 1 to n, then you will need some form of rating system. But that is a crappy goal, and I wonder why companies feel it necessary to do so. It doesn't improve the product, and doesn't make developers more efficient or more productive.

If the objective is to drive specific behaviors that is simple enough to do. Ratings based on easily measured objectives (uch as focusing on bug fixing) will ensure that those metrics are met, most of the time regardless of the cost/benefit to the organization. And if the annual reviews set up competing metrics (QA rated on how many bugs, developers rated on how few bugs) then progress will grind to a halt as teamwork goes right out the window in this zero-sum game.

If the objective is to help people grow in their careers (and this *should* be the objective), then the reviews should not be annual, but much more frequent, quarterly at a minimum. Annual reviews tend to focus more heavily on the most recent quarter, as that is what is freshest in the minds of both the manager and the developer. If you are going to have quarterly reviews then they have to be lightweight. Don't use ratings, but rather focus the review on strengths and weakness, and how those fit into the company's strategic plan, and the developer's personal career plan. Make sure the developer is aware how they are progressing, and knows on which areas to concentrate. Using SMART objectives can be effective here, but they have to be focused enough to be of value. Long term macro objectives (n dollars in gross sales) are not effective at the team level. Individual level Objectives that are SMART and Annual and relevant are a myth. Quarterly objectives are short enough time frame to allow for adjustment to market/company directions without causing the developer to rebel (I am not meeting the annual objective, therefore my bonus is in peril, and I won't be able to afford that family vacation I have been promising the spouse).

Finally, be consistent in the review data. Do not have a quarterly review for results mixed with an annual peer review, mixed with a semi-annual daily behaviors review. Consistency will help drive the message (whatever that message you want to deliver as a manager) more effectively. Have the same information available for each review. If you want to do peer reviews as part of the process, then have them at every review. If the data are not important enough to review quarterly, the do not include that data.

Semi-Bi-Annual Review Time - Part 1

It is that time of the year again, time for the Performance Review. if you follow any Atlassian's twitters, you already know the opinions of many on this topic. They range from the light-hearted dismissial ("trying to find enough synonyms for awesome") to the resigned ("[the] whole agonising performance review self-assessment bullshit") to the cynical (see remainder of the post).

This post is not going to be about Atlassian's review policy, but rather what I believe an review policy should be.

I have been on the evaluatee end of 13 annual reviews while working in IT, and have been on the evaluator end for 8 years. I have done reviews with Excel spreadsheets, word docs, and complicated Performance Review tools. I have rated people on three, four and five point scales. I have filled out self assessments based on SMART objectives, B-SMART-R objectives, free form objectives, and no objectives. For the most part, it has been crap.

So how should an semi/annual review look. Here is part 1 of what I recommend.

Don't give ratings/scores.
Scoring systems suck. The mere existence of a rating/scoring system will render the face-to-face meeting the the employee less effective. If you state the rating at the beginning of the meeting, then regardless of the scale almost everyone who doesn't get the highest will spend the rest of the review wondering why they didn't get that rating. If you wait until the end of the review to tell the employee the rating, everything you are saying in the review is being ignored as he or she waits to hear the rating. It doesn't matter if you rate on a three, four, five, or ten point scale, those who did not get highest can be de-motiviated. There is a massive amount of effort (at least for good managers) spent on preparing for the review, and the return on that effort is minimal if the person is busying composing counter arguments in his or her head on why they should be rated higher.

Rating system cause the end of the review session to be focused on "how do I get the highest rating" questions, rather than "where can I improve and be a better developer" questions. The rating system creates this false premise, that if someone ticks all the correct boxes they will get the highest rating, and you as a manager can articulate the exact requirements to tick those boxes. Of course you can't. It is impossible to have everyone be able to be in the top 10% (because the rating systems always have caps on how many people can be in the top bracket), so you cannot give them SMART and/or B-SMART-R objectives that will guarantee a place in the top rating score group. It also becomes harder to articulate that true superstar performers excel above and beyond any set objectives. They have the ability to solve a problem more quickly, ask more probing questions, etc. You can't socre that using SMART objectives.

A better option is a binary scale: successful or not-successful. The biggest benefit is the refocusing of the review on the details of what the person is doing right and what needs to be improved. With this binary scale, it becomes even more essential that the manager spends time doing a thoughtful, thorough and comprehensive review - rather than giving everyone the same general comments and using a rating system as the differentiator. Couple a binary rating with frequent detailed feedback, and you have a much better evaluation system.

Update: I forgot to mention that the rating system is not improved with cool/impressive sounding names for the ratings. Having 1 be "Totally Awesome" and 2 be "Completely Awesome" will not make the person who got a two any happier.

Bad Analogies Suck.

One of the thing I appreciate about working at Atlassian is that everyone is constantly working on self-improvment. In pursuit of this goal, the Team Leads meet once a week to review and discuss a current leading industry monograph (otherwise known as Book Club).

I learned early on in my academic career that books are not meant to be read as narratives, but rather books are an argument. The author is trying to persuade you that his interpretation of events and/or current practices is correct. One of the worst ways to do this is through the use of bad analogies. And yet, bad analogies seem to be one of the predominate modes of writing in IT books. Bad Analogies distract from that argument, or worse, tend to disprove the very point the author is trying to make.

In Agile Estimating and Planning by Mike Cohn, he has a chapter on Buffering Plans for Uncertainty. When planning for a project with a firm deadline and absolute set of functionality, he uses the analogy of getting on a flight. All the steps (driving to airport, passing security) must be completed, and the deadline is set before the project even starts. To ensure the project gets done, he suggests leaving earlier for the airport. The conclusion reached by using that analogy - start your project sooner. In software development, it is usually not very feasible to solve a scheduling problem by going back and starting the project sooner. The normal solution is, of course, to delay release (take the later flight) but the point of his argument was to show how Agile planning can help make that first flight. It is better however than the next analogy I encounter at Book Club.

In Release It!, Michael T. Nygard uses the analogy of a car that fell apart on the test track to show that even when the process works correctly, bad products can result. In other words, he argues that a failed QA effort proves that successful QA doesn't guarantee a good product. Now passing all QA tests doesn't mean the product won't suck, but that point is lost when the example contraindicates the argument.

The irony is that both of these books are really good. They have good insight, and provide practical guidance on how to do agile planning and build robust systems respectively. I just wish they didn't make it so challenging to agree with their arguments.

Sarcasm - one of the many services I provide.

Cynic (n.) - a person who shows or expresses a sneeringly cynical attitude.
- One who expects things to go wrong.

Cynical Software Manager (n.) - me.

Welcome to my blog. The idea for this blog came as a result of many a conversation with Mel, the Program Manager at Atlassian. Over the course of several IMs and actual face-to-face discussions, when I find myself discussing something stupid, I usually make a smart ass remark, and call it the title of the next chapter in my forthcoming management book. Given that I have no intention of ever writing a management book, those chapters will now be blog posts. The recycling saves me from having to think of new interesting things to write about, I can just write about old interesting things. And remember,
if it was written in a blog, it has to be true.

The title of this "chapter" is in honor of my penchant for being a sarcastic smart ass when dealing with people, even those I like. Especially those I like in fact. And the reason is that sarcasm can be extremely effective in interpersonal communications (or at least I think so, after all I am in software development, so I don't ever get around to talking to real people). An example, you ask, where sarcasm can be useful in the workplace. The best place is in meetings, where using the inherent humor in sarcasm can deflect any notions of personal criticism. It can also be effective in pointing out patently obvious points that were somehow missed, or to illustrate unreasonable expectations. I hope it works, otherwise I have been pissing people off for real for a long time now.

And I am cynical enough to realize that my meager sarcasm skills pale in comparison with the true masters, the cynics that believe nothing will ever get better or be done right. Since I am a very optimistic cynic, I really believe that the project will be a success, and will be finished only a short time after the scheduled release date, once the inevitable happens and is corrected.

It is also difficult to be a full-blooded hard-boiled cynic (first definition) when you work with great people at a great company. And I am not so cynical to be disappointed about that.