Monday, December 28, 2009
I've been following Elisabeth's announcements along the way to making this happen, and from what I can tell, the Agilistry facility is set up as real agile working space... except conceived and designed from the ground up by some of the most intelligent, experienced agile practitioners in the world today.
When I think of "training space" for software, I think of a trainer behind a podium with a whiteboard and a projector and some handouts, with trainees sitting at tables facing the podium.
This isn't that. Agilistry isn't training space at all; Agilistry is *practice* space. It even says so on the web site: "Agilistry Studio; a practice space for Agile software development"
And I'll bet that not many people know how to use a practice space.
For beginners, practice space is expensive but very possibly worth it. Say for instance that management informs your development organization that next month you will be "going agile". They're going to dismantle your cubicles, bring in some tables and whiteboards and index cards and sticky notes, and they expect your productivity to soar.
As a beginner, your first responsibility is do your research, improve your skills, set some reasonable goals, that sort of thing. But if you are going to be thrown into the soup anyway, it might be a good investment to get as good a start as you can. A beginner team at Agilistry won't be able to take advantage of (or even recognize) the more sophisticated aspects of what Agilistry is offering, but getting off on the right foot could very well mean the difference between success and failure. Having the Quality Tree staff available in such a well-designed space would be a huge boost to a beginner team. If nothing else, Agilistry can prevent beginners from having to rearrange the furniture every day until they get a good configuration.
Practice space is critical for intermediate groups. Intermediate groups have enough experience to have gotten some taste of success, but still need to adjust, and practice, and analyze, and adjust, and practice... Because intermediate groups have had some success, they are often under intense scrutiny. A practice space is a place where the group can go by themselves to work slowly, do a lot of analysis, make a lot of mistakes, and correct them, or at least protect themselves from making the same mistakes again and again. This is the biggest stumbling block I see for intermediate groups: so many of them retreat to a practice space only to make the same mistakes in the same way, sometimes without even recognizing that they are making mistakes. I see having the guidance of the people from Quality Tree available to help intermediate groups is the best value Agilistry offers.
Advanced groups have the skill and experience to learn new concepts and implement new practices instantaneously in the course of their work. For advanced groups, the value of practice space comes when one project ends and another begins. As long as the team is stable and the goals are well-known, an advanced group can implement new ideas on the fly, without really needing practice space so much. But when the goals are met and the project ends, and it comes time to start a new project or to gather a new team, having a separate practice space to repair to for planning and practice is invaluable.
Finally, a practice space provides a community. Groups move in and out, groups meet each other, groups exchange information about what they work on while they practice. Over time, a practice space can generate an entire "scene" of groups that know and respect each others' work. Knowing Elisabeth and Quality Tree, I have a feeling that will happen.
We musicians know all about practice space. Beginners have to rearrange the furniture in the garage. Intermediate musicians scrimp to rent a smelly soundproof room in a warehouse somewhere. A touring band can rent or borrow an empty club stage. Sting rents a fully-supplied medieval castle in France for the whole group, but only for a few weeks until the band goes on tour. I've rented every kind of practice space you can imagine, from dingy rooms carved out of warehouses to fully-equipped stages. Having a "practice space for Agile software development" fits right into my notions about how proper software development should be supported: the more the agile development environment resembles the ecosystem that supports the performing arts, the better performers that environment will produce.
Congratulations Elisabeth and Agilistry!
Saturday, December 12, 2009
Marisa is doing the coding (so far; I've never written any Java and would like to learn) and I'm being something like a Customer. I've used similar tools in the past, and I know what I want this tool to do.
Eventually we're going to need documentation for our first release (0.9?), so it seems like a good idea to write down what we're doing, and this seems like a fine place to do it.
The first thing is that we want to change the name of the project to avoid confusion over the other tool with the same name, Canoo WebTest. My favorite so far is 'Selenesse'. Not only does it give a sense of the bridging nature of the tool, it also is very close to the word for the high-level selenium language known as 'Selenese', and since Selenium borrowed a lot of structure from Fitnesse early on, it's kind of poetic to bring it back around like that.
Marisa wants to host the project on Github not Sourceforge. I've used them both, so that switch will probably happen. This has the added benefit of leaving the old project on Sourceforge if anyone ever has a use for it.
We're going to change the namespace not to use "neuri", Mr Adzic's own company name.
The project will support SLIM and scenario tables from the beginning. I'm really liking scenario tables.
The project will have better support for Se-IDE-reported convenience methods. For instance, we've implemented support for clickAndWait, with more such coming.
The project will have a new approach to methods with two arguments. Because of how SLIM is built, methods with 2 arguments such as type() or select() that are normally spelled
| type |
| select |
are implemented as
| type |
| select |
In the course of working on Selenesse, Marisa has also become a committer on the Fitnesse project, so eventually we can support both styles of 2-argument commands.
One big change we're making is to have all Se commands return boolean values to Fitnesse. (This is what makes Fitnesse turn a line red or green; otherwise, if the command fails, Fitnesse returns an exception not a test failure.) At the moment, WebTest returns boolean values only for explicit assertions such as verifyFoo or waitForFoo. I want to emulate SWAT and WikiTest and have every test step return a boolean so that Fitnesse records each test step as a pass or fail. I have a long justification for doing this I've written about elsewhere.
Except that we hit a snag with this. We found that we need the Selenium command check(). Unfortunately, "check" is a reserved word in Fitnesse/SLIM. My suggestion here is to emulate WikiTest and Se-RC in Perl, which provides two versions of each method; a method that does not return boolean, such as click() or check(), and a method with the same name with 'Ok' appended that *does* return a boolean, e.g. checkOk(), clickOk(). If I'm not mistaken, this scheme is available in Se-RC in Perl, so having both versions of the method available would add a certain amount of compatibility between Selenesse and (at least) Se-RC in Perl.
At the moment all our work has been in Java, but already we have interest from a .NET user who may join the project also. The Java work is going to take priority, because we need that for our real job, but .NET support should come along eventually.
Finally, I have to acknowledge my own deep respect and gratitude for the people at Socialtext and at Ultimate Software who build the WikiTest framework and the SWAT tool. I've been an expert user of both, and Selenesse will be borrowing the best features of both projects.
Selenesse, though, will be far more portable, with far fewer dependencies than either SWAT or WikiTest.
Tuesday, December 01, 2009
So we wrote one. The following document has been through more than 80 revisions and contains text contributed by 5 separate authors, and also reflects the comments of even more participants. We hope you find a generic telecommuting policy useful.
Some organizations want to offer telecommuting as an amenity for work/life balance. Other organizations do not want to have to rely on local talent to build exceptional teams. Other organizations want to use telecommuting to reduce the cost of infrastructure such as office space.
Regardless of the reason, any organization wishing to succeed with telecommuting must have a policy for handling remote working. An institutional standard must be in place such that everyone telecommuting or interacting with remote workers has had a similar experience using similar tools to accomplish similar work. This is such a policy.
Any team member who wishes will be allowed to telecommute if: the whole team agrees to monitor and be responsive on all of the communication channels required by the organization for telecommuting teams. Team members doing solo or pairing work must keep the rest of the team apprised of their status, and should not be incommunicado for long periods of time.
Telecommuters who are not responsive on all of the required communication channels will be questioned and may be subject to having their telecommute privileges revoked or other disciplinary action.
Here we describe how to implement this simple policy.
For Telecommuting Beginners
As stated above, an effective telecommuting culture makes constant use of a set of communication channels. As a first step to implement this mode of working, an organization with little experience with telecommuting can have an expert supply compelling, collaborative training sessions, presented using teleworking technologies. These high-value training sessions provide a focus as the organization implements these policies and procedures for the first time, or consolidates such procedures already in place, and supplies incentive for everyone attending to participate and contribute. Although everyone will attend the training via the communication channels, interacting with the trainer, the material, and one another electronically as though they were telecommuting, training may take place locally and some or all attendees may be co-located. This enables smooth technical support and a controlled experience, affording natural opportunities for feedback on the policy.
Prepare the Team and Prepare the Environment
We strongly recommend that the organization put an IRC (Internet Relay Chat) server in place and have everyone in the organization know how to use it. The authors do not know of another messaging service that provides even a fraction of the features available in IRC. We recommend an institutional channel like "#social" for casual messages like "how was your weekend", as well as institutional channels for groups that collaborate closely, for instance "#dev" or "#my_team".
Before the remote training session begins, the following equipment must be in place for every member of the team:
- A working headset
- A VNC server and client for desktop sharing (1)
- A working instance of Skype, or other VOIP service that provides conference-calling ability (2)
Agree to Participate
Every member of the team must agree to participate in all of the communication channels required by remote workers. During business hours, every member of the team must be monitoring at least the following channels and be prepared to answer on them quickly when appropriate:
- instant messaging such as Yahoo IM, AIM, or similar service
- yahoo IM video (3)
- wiki (4)
- IRC in both #social and #
We consider these channels to be a minimum standard for telecommuting. Telecommuters require high bandwidth communication channels to be effective. If they are disconnected from the ongoing work of others on the team, the lack of critical information will make them unable to contribute; the risk of wasted work is far higher than for those on co-located teams. Having a required set of standard institutional communication channels mitigates the risk of wasting the work of telecommuters.
Other communication channels like a microblogging service, IRC interfaces to Twitter or Facebook, or other such communication channels may also be appropriate. The authors are aware of at least one organization experimenting with virtual worlds like Second Life for distributed teams.
Ongoing Remote Working
The organization must have a telecommuting policy to refer to once the training sessions are finished. Since we have built an institutional standard, where all of the telecommuters who participated in the training have had a similar experience, using similar tools to accomplish similar work, we can now put such a policy in place.
Upon finishing any required training, any team member who wishes will be allowed to telecommute at will under the same requirements that were agreed to when working in the training session: the whole team must agree to monitor and be responsive on all of the communication channels required by the organization. Team members doing solo or pairing work must keep the rest of the team apprised of their status, and should not be incommunicado for long periods of time.
It should be understood that telecommuters who are not responsive on all of the channels mentioned above will be questioned and may be subject to having their telecommute privileges revoked or other disciplinary action.
During the training experience, we assume that some workers were on-site, interacting with the trainer (and with each other) using the channels described above. When such workers are remote themselves, there may be a need to have on-site workers available on their office phone extensions. The open source PBX project "asterisk" supplies VOIP connections to office phone extensions, as do a number of commercial phone applications such as Avaya.
Meetings should be structured such that remote employees can participate on an equal basis with those on-site. On-site meeting rooms must be equipped with adequate speakerphones. A multi-user IRC or IM 'back channel' where both on-site and remote participants may comment on the ongoing discussion in the meeting increases meeting bandwidth and makes it much easier for telecommuters to raise interruptions.
Travel requires a careful balancing act. Face-to-face time allows coworkers to connect on a human level and can be incredibly productive and beneficial. However, full-time telecommuters are telecommuting for a reason, and mandatory travel that inflicts hardship upon them harms the company in equal measure. Have a clear travel policy for telecommuting workers.
(1) Desktop sharing is required, both for pair-programming and for demonstration of issues with software. Employees should be able to screen-share spontaneously, without the need to schedule a slot in advance. Tools such as Microsoft LiveMeeting or Webex or YuuGuu may substitute for the open source VNC. When working in a *nix environment, screen(1) is more productive than VNC for collaborating in a text-only environment. Examples of when to use screen(1) are, for instance, when using Vim or when doing system administration from the command line.
(2) The open source 'asterisk' project provides a professional-level PBX with multiple conference-call and office numbers available. Proprietary tools such as Avaya or other systems may provide the same sorts of features. What is required is the ability to have a group of people speaking together without echo, distortion, or other interference. Employees should be able to hold impromptu conference calls without the need to book a conference extension in advance.
(3) Some people find video screens of individuals unnecessary if those individuals are available on other channels. For remote workers interacting with an on-site team, having a camera in the team room is valuable so the remote workers can see who are at their desk, or engaged in conversation, or otherwise disposed.
(4) Teams need to manage significant amounts of project documentation and other text. Storing documents on network drives and sharing documents by email is far too low-bandwidth for remote workers to negotiate effectively. As well, these media do not allow for effective multi-user collaboration, nor do they provide an easily accessible revision history for documents, nor do they provide a single authoritative place to access a given document. A full-featured wiki like Confluence, Socialtext, Mediawiki, or Twiki is required for the access to constantly changing information that remote workers need. In our experience, Microsoft SharePoint has shown to be subpar for this purpose.