Job Posting

Job posting has been nothing short of an art these days. You want to attract the talent by describing the job as challenging and the environment as fun. Of course, it always helps if it is really the case.

Fortunately for me, this is the case for Development Operations team at Guidewire. And fortunately for me, I got a lead who cares deeply about attracting the talent, and he drafted the following posting by himself.

Development Operations Engineer

Foster City, CA, United States

How we hire
We’re looking for someone who’s good for the role, good for Guidewire and good at lots of things.
Things move quickly around here. That means we have to be nimble, both in how we work and how we hire. We look for people who are great at lots of things, love big challenges and welcome big changes. We can’t have too many specialists in just one particular area. We’re looking for people who are good for Guidewire—and not just for right now, but for the long term.

How we interview
We’re looking for smart, team-oriented people who can get things done. When you interview at Guidewire, you’ll likely interview with four or five team members. They’re looking for four things:

Leadership
We’ll want to know how you’ve flexed different muscles in different situations in order to mobilize a team. This might be by asserting a leadership role at work or with an organization, or by helping a team succeed when you weren’t officially appointed as the leader.

Role-Related Knowledge
We’re looking for people who have a variety of strengths and passions, not just isolated skill sets. We also want to make sure that you have the experience and the background that will set you up for success in your role. For engineering candidates in particular, we’ll be looking to check out your coding skills and technical areas of expertise.

How You Think
We’re less concerned about grades and transcripts and more interested in how you think. We’re likely to ask you some role-related questions that provide insight into how you solve problems. Show us how you would tackle the problem presented--don’t get hung up on nailing the “right” answer.

Fit at Guidewire
We want to get a feel for what makes you, well, you. We also want to make sure this is a place you’ll thrive, so we’ll be looking for signs around your comfort with ambiguity, your bias to action and your collaborative nature.

The Position

The area: Development Operations
Development Operations provides a solid infrastructure to enable our development team to quickly and efficiently develop new products. This critical team combines software development, software administration, and product management expertise to support our Guidewire development team. As the primary infrastructure team at Guidewire we have the ability and responsibility to make decisions that will benefit Guidewire in the long term.  We provide an infrastructure on which Guidewire can cost-effectively scale.  Every member of our team is expected to provide new ideas, while we work as a team to prioritize and accomplish the work that gives us the most bang for the buck.  We can't do it all ourselves, so our job is to communicate with those outside of DevOps to establish healthy working relationships needed to support work of Product Development and by extension our own work.  Our job is to educate our users to prevent fires from happening.  We can't prevent them all, but we can identify risk areas ahead of time and build an infrastructure on which we can quickly respond.  We hire creative engineers and technology enthusiasts who enjoy being challenged by organizational problems, with a strong desire to make services better for users.  Our teams come from diverse backgrounds, and we are actively seeking new team members to bring fresh perspective to solving problems, along with the technical and soft skills needed to keep Guidewire's services growing and reliable.
The role: Development Operations EngineerYour job is to understand the daily activities of our development teams and constantly think about ways to make them more efficient.  This includes:

• Listening to individuals across development, understanding their activities, and constantly thinking about ways to make it more efficient
• Searching for suitable software and tools
• Making recommendations
• Purchasing software
• Install, configure and administrate tools with support from our Information Technology and Systems department
• Giving presentations about the software tools
• Documenting your work
• Finding ways to provide training materials
• Being the software system administrator and expert for JIRA, including:
  
  • Designing and implementing workflows
  • Building custom plugins
  • Identifying and deploying 3rd party plugins
  • System administrator systems like Confluence, Mediawiki, GitHub, Perforce, Nexus
  • Lead projects across Development, Information Technology, and Information Systems
• You will scale your job by encouraging organizational learning and self-sufficient teams
• You will encounter challenging, novel situations every day, and work with just about every other engineering team and department at Guidewire
• You will be looked upon as an expert and advocate to fellow engineers

The ideal candidateWhat drives your work?

• More than a paycheck, you love your work and want to maximize your positive impact on the people in an organization.
  

Minimum Requirements

• BA/BS in Computer Science, Computer Information Systems or related technical field. (In lieu of degree, 4 years relevant work experience).
  
• Strong written and spoken English language skills
  
• Solid communication skills
  
• 1 year of experience at a small startup company or a startup-type team
  
• 1 year of software system administration experience
  
• 1 year leading a project to accomplish a goal
  
• Do it yourself experience with Linux and Windows
  
• You have served as an expert in 1 or more areas at a company
  

Additional Requirements
You should meet about 8 of the following 12 requirements:

• 1 year in project lead or similar role
  
• 1 year in tech support or similar role
  
• 1 year in quality assurance or similar role
  
• 1 year coding software using object-oriented techniques (in order of preference, Java, .Net, C++, Python, other)
  
• 1 year hosting software as a service
  
• 1 year as a doc writer, or otherwise extensively documenting your work
  
• Experience troubleshooting web browser experiences: Internet Explorer, Google Chrome, Mozilla Firefox
  
• Experience with Linux and Windows as an administrator
  
• Experience with Linux systems requiring the use of scripting languages like Python, Perl, or Shell
  
• Experience with Windows and Mac/Linux as desktops
  
• Experience with Kanban or Scrum as a user
  
• You have built your own product or service which is/was used by 10 or more people.  This could be internal or external
  

Example Profile
We don't expect someone to match this exactly, but the ideal candidate will have this kind of breadth of experience:

• 2 years of experience running and building a 2-3 person technical support organization
  
• 2 years of being the only QA for a 4 person development team
  
• 3 years of experience on a 2 person team hosting software as a service for 80+ customers
  
• 4 years of experience building a customer facing product from scratch, deploying it to 20 customers, and supporting it.
  
• 4 years of platform development using object-oriented techniques in VB.Net and VBscript
  
• 1 year of experience writing an 80 page user guide to be used by over 300 customers.
  
• 1 years of experience building a test infrastructure to automate deployment and running of automated tests
  
• 1 years of experience leading a team of two to run those tests automatically across a large swath of servers.
  
• 1 year of experience preparing a merge of a QA department into a Development (Coding) department.
  
• 7 years of experience serving as an expert on JIRA, even though it wasn't your job.
  
• 2 years building and supporting a tool that is used by 200 developers.  The tool is part of a customer facing solution, which you built the first fully functional version of.
  
• 4 years of experience doing platform level JAVA Enterprise development

Leadership Trio - from the Beginning

(All names here are fictional, and I recommend the readers not to think if they are based on any real characters. The point here is to tell a story about an idea that can be very interesting)

"You should write this down." Andy told me, "The result of your effort is the change in us three leads.We are very happy with how you have coached us and provided clear opportunity for growth. But others in the company might not see it that way. They will see the three of us getting things done and nothing from you. And they will find reasons that they can believe for things that they don't understand. You need to communicate about your work, maybe in the form of blog."

I brushed it off initially, thinking with my work during the day and school during the night, the last thing I want to do is to keep a blog about what I am doing at work. But that idea grew on me. After all, we should only brush off ideas because they are not good, not because we are too busy. Doing so would lead to the possibility that we might be spending effort on less worthy ideas right now and might be wasting our lives.

So here I am, backtracking the footsteps of this most rewarding journey that I have stumbled upon as someone who is searching for the leadership style that fits me as a team member, a manager, and in the future, as a leader of a business unit or organization.

Prelude

The form of trio was the result of nothing more than pure luck. As I am getting to know the team and the operations after moving over one year ago, I slowly realize that I have been blessed with three capable leads. Believe it or not, it takes some training to be able to reach that realization. Andy, Vitaliy and Bernard are the leads who are ready for further career coaching. I have now established a good relationship with them. At the same time, I took the "Total Leadership" class in Wharton MBA that involves putting myself through a leadership coaching process. While still in the training myself, I can see the power of the coach framework. By the time that my training required me to design experiments that served the interests of my stakeholders and achieve four-way wins in the area of work, community, family and self, the idea came to mind to apply the same coach framework to the leads.

The format of my training made it pretty easy for me to write down essential elements for the experiments. I discussed them with my coaches (TA, Alumni coach and my coach trio) and received positive feedback and strong encouragement.

I talked to the leads, confirmed their desire to be responsible and accountable for all aspect of their teams. I also got their agreement to form a trio as part of their training process.

Leadership Trio

Originally, I called this "Management Trio". However, the term "manager" has raised more eyebrows than I anticipated or wanted to deal with, because of its association with the HR policies and legal implications. Whatever the term is, the idea is to let the team also understand the non-technical side of the team operations. The purpose is to let members with technical background be involved with major decision-making and have a taste of life outside their normal realm. It serves as a natural career path for those who have the potential to become full-time manager, which is extremely valuable yet hard in a technical startup. It can also serve as a valuable education ground for those who decides to remain technical. The extra knowledge will make them more valuable because they can support the managers better.

The trio structure provides quite a few benefits. It provides the check and balances it needs while supporting the coaching style management. It provides a good self-learning foundation, which is more valuable in a process where the main purpose is to promote learning to build a functional team. By leveraging the existing core competency and resources, the trio can effectively work through the challenges. By providing supporting structure for real-life learning, the trio structure can be easily duplicated elsewhere and can lead to grassroots movement.

From the manager's standpoint, this structure is aligned with the change of management style in fast companies. The people with the best information are making decisions. The job of the managers is to communicate and coach the team so that the objectives and incentives are aligned and the teams are making the right decisions. Our company has recently grown from a start-up to a publicly traded company. As tit has grown, I have witnessed many cases where people turn to a manager to make decision for them or the manager steps in to head decision-making process. These behaviors have been pulling us away from the goal of always searching for innovation in organization structure and team governance. We should be mindful of the example set by companies such as GE, Semco who have maintained a culture of innovation despite their tremendous growth. We must make sure we don't lose the innovative culture we have built here.

Leads

It is still hard to say what kind of people are suitable candidates for this trio. For that I consider to be extremely lucky because I didn't have to go through the interview process. The most thinking that I have done was to look at my current three leads to decide if this serves their interest, and if they are ready for something like this.

Vitaliy brings his understanding, voice of reason, and good communication to the trio. Eager to learn and eager to help, Vitaliy has been the natural leader of his team. Vitaliy has a good way of communicating externally as well as internally, especially in contentious situation. I have learned much just by observing his interactions with others. Vitaliy provides good understanding and voice of reason which generates trust in the trio.

Andy brings his capability of strategic thinking under fire to the trio. Andy has been operating in a challenging environment for a year. He survived and delivered a major internal system upgrade single handedly, which is no small feat. While others like me always have the tendency to jump into any request and help people out, Andy has established a good practice of looking at the requests based on the urgency and impact, possibility of user error, so that he can address those who really need his help, and push the rest to learn to be self sufficient. There is always a contention with this model, and he has walked the fine line for over a year, and survived. This gives him the time and energy not only to survive, but also to think strategically about what we really need. This is how he was able to recognize the need to research and implement the solution ahead of anyone else in the department. Examples are the service level of certain servers, the disaster recovery readiness, the cost and benefit analysis for the medium term projects in the next two years.

Bernard brings in his style of Charisma to the trio. That statement is not as tangible as the two above, and that is because he has been in the shadow of the former leader until recently. There are a lot of signs showing that he has the capacity to lead and he has made it clear that it is his career interest. He has been watching the operations of Vitaliy, understand its value and want to learn the art of adopting it to his team. He has been learning about our build system and wants to migrate the system to fit more into that model. I have sat in quite a few user meetings and they all went very well. Bernard is confidence in voicing his opinions, while still take others input into consideration.

All three leads are smart people with good grasp of concepts and understanding the importance of business operations in additional to the pure product development. They learned the elements of operations on the job and acquired practical skills to succeed as a leader. At the same time, learning in a resource restrained environment has made it difficult to slow down enough time to look at the business as a whole and think about strategic plans, especially where there is no guidance or training about how to do that. All three leads are known for their capability of listening to people and making good judgment calls in terms of functionality and urgency.

Each lead also has his own areas for improvement. I am not comfortable listing them here, yet, as it is highly personal. I do plan to invite them to be the writer of this blog to see if we can fill the missing information here.

Preparation

The only preparation is to make sure the leads are ready. Being a lead is a rewarding and challenging journey, and it is certainly not in the interest of every software engineer. During the one-on-one meetings, I talked with the team leads about their strengths as well as areas for improvement. Instead of simple praise or passing of critical judgment, I focused more on the future of the team. What do they want to do achieve for the team and for themselves, and what is preventing them from doing it? Through that conversation, I brought up the trio framework and they all signed up immediately. That was definitely a good moment because I was off to a good start.

Session I - Kick Off

The first session is the kick off session. I want to bring the coaching dynamics in the one-on-one to the trio. To do that, each lead needs to learn more about each other and be aware of the desire and strength of each other. There will be time for them to learn about the area where each other needs help with but that will come later.

We went around the circle asking the question: What is your goal? What would you like to achieve for the team and for yourself? The answers were interesting such that they are on different level: relationship with customers that we are serving, the value we are bringing to the company, and the technical innovations that we can foster within the team. This is another sign that the trio is a versatile group.

The second round of question was: Identify one thing that you can bring to the group that others don't necessarily know about. I don't have the notes on the answers but I remember we got good laughs. My goal of building rapport among the trio was definitely achieved.

After that round of exercise, it is the experiment framing stage.

"This is an experiment that will benefit Guidewire as well as us individually. By experiment I meant that it can fail, even though the chance of success is high. This is an idea that I have thought through, and have got feedbacks from others. As of now, you three are part of a trio for learning about team and organizational management. You will practice and learn how to coordinate on behalf of your team. You will learn how to reach non-political agreement."

Then I open the floor to let the trio talk. The topic was mostly focused on how much this is needed at this stage of personal growth and company growth. I think we also touched on my role in this and my answer was that I will assume the coach role and I expect them to reach decisions through peer discussions. The lead could and should look for me for advice and I would still focus on talking through the issues and help the leads reach decisions.

The next two questions are based on the feedback I got from my coaches. How would the trio reach agreement on decision? At what point would we know that this is not working?

For the first question, the agreement was to talk about it through open conversation. Later, we moved this to an online chat room, so that the conversation can keep going even as we are busy with other tasks, and even when we are remote.

For the second question, the answer was that when things are being dropped, that would be the sign. I agreed to keep sending feedback whenever I want the confirmation that things are not being dropped.

The meeting then adjourned, marking the start of trio.

Bonus System

A bonus system is to be designed with the idea that it is a motivation tool. Its purpose is to maximizing the desire of the members to do better. While there is certainly some benefit of paying attention to only a small number of elites in the organization, the effectiveness of a bonus system  can reach to majority of the community, including those who don't receive the bonus.
There are many articles, case studies, blogs, videos and theories around motivation and reward system. When it comes to bonus system, it helps to think from two perspectives: equity and expectancy. They can be applied to understand the motivation oriented compensation. To reach a solid structure for a particular company, other factors like the history, recent events, and members also play a big part.

Equity Perspective

One way or another, individuals will compare their job inputs and outcomes with those of others and then respond to eliminate any inequities. People have strong psychological reactions to fairness in how they are paid and these need to be managed carefully. Given the uncertainty of bonus for each year, this psychological need is especially strong during the payout period. A effective bonus system can present enough degree of fairness and continue motivate even those who don't receive them. When not managed carefully, a bonus system can generate anger for the under-rewarded, guilt for the over-rewarded, and confusion across the organization, thus defeats the purpose of the bonus system as a motivation tool.

When inequity is perceived, the result can be damaging. Some will lower their input; some will change their outcome (e.g. increased units produced at lower quality); some will distort perception of self; some will distort perception of others; some will choose a different reference for comparison; and mostly commonly in silicon valley, some will leave the field or the company.

The key element here is an individual's perception of justice. While the differences of opinions make it hard to manage, the subjective element suggests that the most important piece is the perceived fairness of the process used to determine the distributed rewards. For employees to see a process as fair, they need to feel they have some control over the outcome and feel they were given an adequate explanation. It is important for the manages to be consistent, unbiased, make decision on accurate information and is open to appeals. This is why it is important for managers to provide early feedback as well as frequent feedback to detect inconsistency and gather more information base on the reaction from the employees. This interaction is more important in the case of bonus, because there is an implicit reset after each year. At the beginning of the year, the employees and the manager start the process again by providing the employee an opportunity to present his or her point of view about the desired outcome to decision makers.

Expectancy Perspective

The following picture illustrates the expectancy theory (source: Wharton MGMT 621 class material)

In practical term, employees will be motivated to exert a high level of effort when they believe that effort will lead to a good performance appraisal; that a good appraisal will lead to organizational rewards such as bonus, a salary increase, a promotion, or a public recognition; and that the reward will satisfy the employees personal goals.

This is particular applicable to bonus because of the one time nature of the rewarding system. The reward only applies to the past review period, thus giving managers and employees a common ground to repeat the motivation process on annual basis. Among others, bonus remains as a desired outcome for most employees because it is always extra money that is in proportion of the regular income. In this case, an effective manager will be able to build the shared connection between performance to outcome, and from effort to performance.

Performance to Outcome: While it is easy to define outcome (bonus rewards) and performance (annual appraisal), it is harder to build the connection from performance to outcome in an organization where there are different teams and roles. The perspective of equity mentioned above goes a long way to design a process that can be perceived as fair.

Effort to Performance: In the context of bonus system, the manager can set goal ahead of the time, and use it for performance appraisal. When the right goals are set, the employees can see a strong connection between their effort and the performance rating they will get. The most effective goals are difficult but not impossible, specific, and have to be accepted by the employee. Another way to describe the criteria of a good goal is SMART: specific, measurable, attainable, relevant, and time-bound. These criteria, especially time-bound, fit very well in the bonus system.

In Conclusion

It is always a challenge to design a reward system in a corporate setting. That challenge applies to the bonus system as well. When it comes to bonus system, however, one can gain deep insight by being informed and continue thinking in the perspective of equity and expectancy.

Blog of the day

Interesting article because it relates exactly to what we are going through.  I am only wondering about the stage we are in

Top 10 Reasons for Slow Velocity

http://www.svpg.com/top-10-reasons-for-slow-velocity/

My current challenge at work is to capture velocity reliably, but I am sure this post will come handy sometime down the road.

Automation of Burn-up and Burn-down charts using GScript and Entrance

I have always found that the burn-up and burn-down charts are very informative and fit to the iterative story-based development very well. Every project that I work on, I will try to figure out different ways to generate burn-up and burn-down charts.

Two months ago, I took the job on putting Platform on Sprints. After some consideration, I have decided to follow the setup that I have for the AF team, creating the stories in the form of JIRA issues. However, the chart generation that I had for AF team was still semi-manual, which means that it takes a couple of minutes to download, and a couple of minutes to update the stats every morning. The worst part is that when I get busy or sick, I will forget.

So my first action item was to figure out how to generate the same kind of charts with the push of a button. The idea seems to be easy enough:

1. Figure out the search criteria to retrieve all the JIRA issues of the backlog
2. Count the issues that are in different states
3. Update the data with the counts, and check it into Perforce.
4. Refresh the chart with the updated data
   

Number one and two were actually not that hard, because Guidewire GScript has a nice WebServices support. With a few tries, I was able to count the beans.

Here is an example of the data generated. I think you get the idea just looking at it.

Date,Day,Closed,Deferral Requested,In QA,Open Stories,Open New Features,Open Bugs
10/09/2009,41,55,0,1,13,7,40
10/12/2009,42,55,0,1,14,7,40
10/13/2009,43,56,0,0,14,7,40
10/14/2009,44,56,0,0,16,7,41
10/15/2009,45,56,0,0,21,8,42
10/16/2009,46,58,0,1,19,8,42
10/19/2009,47,58,0,2,28,8,42
10/20/2009,48,58,0,6,26,8,42
10/21/2009,49,58,0,6,26,8,42
10/22/2009,50,58,0,7,25,8,44

Number three took less time but a bit of research because Perforce Java library's API is not exactly straightforward.

It took me a while to figure out how to do the last one. After looking into JFreeChart and Google Chart API, I eventually turned to my dear friend, Tod Landis, who is also my partner at Entrance, and he quickly drafted an entrance script for me. Based on it, I was able to write a template that can be used for all teams within a few hours.

PLOT
very light yellow area,
light yellow filled circles and line,
DATALABELS
very light orange area,
light orange filled circles and line,
very light red area,
light red filled circles and line,
very light blue area,
light blue filled circles and line,
very light gray area,
dark gray filled circles and line,
very light green area,
dark green filled circles and line,
all AXISLABELS
WITH
ZEROBASED
TITLE "Sprint"
TITLE X "Days"
TITLE Y "Points"
SCALE Y 0 100 0
CLIP
legend
gridlines
collar
no sides
SELECT
`Open Bugs`,
`Open Bugs`,
date,
`Open New Features`,
`Open New Features`,
`Open Stories`,
`Open Stories`,
`In QA`,
`In QA`,
`Deferral Requested`,
`Deferral Requested`,
`Closed`,
`Closed`,
day
from report;

Please note this is the final PLOT script, there are other SQLs run before this to import the data into the MySQL database, sum up the data to produce a stacked chart, and even out the labels.

And I now have this chart generated automatically every morning with the help of a windows scheduler.

Cotta Asserts vs FEST Asserts

Background

Cotta-asserts is a public release of the JUnit 4 assertion adapter that came to as part of the Cotta implementation and my search for a better sematics for assertions in test.

FEST-Assert is a Java library that provides a fluent interface for writing assertions. Its main goal is to improve test code readability and make maintenance of tests easier.

• Cotta-asserts: http://cotta.sourceforge.net/assertions.html
• FEST-assert: http://fest.easytesting.org/assert/wiki/pmwiki.php

Bottom Line

The bottom line is that these two libraries are trying to solve the same problem in a different way, so they are both viable solution for writing assertions through fluent interface. Even though personally I like what I have built, I would not argument very hard about using one versus the other, same way as I would never argue between JUnit and TestNG, even though all my projects have been JUnit (And I know some people feel strongly about it).

I can also say the same thing about Java versus Ruby. When it comes to the bottom line, having a gelling team building high quality software that makes the user happy is all I care.

Why I like FEST asserts

Don't get me wrong, I love FEST asserts. Their API looks solid and really complete. Even now, Cotta Asserts still has some way to go to catch up, it is simply not high enough on my list, and I have not found anyone willing to contribute.

Why I like Cotta Asserts

With that said, I think it is worth it to write down the reason that I like Cotta Asserts.

First of all, Cotta Asserts is aimed to filling the gap of JUnit and Hamcrest, nothing more. It is just an API adapter that exposes the assertThat method in JUnit 4 and the matcher classes in Hamcrest. If one day this fluent API appears on the new JUnit release, I would be happily retire this little side project, and get back to the next item of my long list of things I would like to try as an open-source project.

Second, you can extend Cotta Assert however you want it to be, because all the classes are open to extension. You can extend AssertionFactory and add more methods to return other assert objects. You can make your AssertionFactory return different StringAssert.

For FEST-asserts, I always wonder why they made the classes final. It does not seem to serve any purpose. Then again, I never asked, so there could be some good reason behind it.

If you have been using assertThat method in JUnit, chances are that you already have a bunch of matchers lying around, and probably start having trouble remembering where they are. You just need to create your AssertionFactory and Asserts to leverage them and you don't have to throw anything away or even change anything.

With FEST-asserts, when you look at an API like this, something is just not right...

FEST-asserts requires you to add one assertThat method for each object type that you want to run asserts on, and one method for each custom condition. It can get confusing sometimes if you have different modules that do assertion on different objects in the module.

With Cotta Asserts, you only need one field declaration from the super test case class, and everything just goes from there. So it is really easy to set up, and really easy to customize it so that each module can have methods that only create asserts that are applicable to the module.

So here you are, happy testing!

Touché

(This one definitely falls in "Energized Work" category)

In an email thread with my old XP mentor and a long time friend, Rob Myers, about coordinating the next BayXP gathering, I mentioned that I have another baby coming soon.

Rob: "... about time!"

Shane: "... are you saying that I should get a life and stop messing with this thing called 'agile'?"

Rob:

"Au contrare my friend. Living 'agile' is supposed to provide you with the opportunity to have a life beyond the office. We should coach through example! :-)"

Shane:

"..."

"..."

"Touché"

"..."

"I think this deserves a blog post"

JUnit Assertion Adapter

I have been trying different assertion styles ever since I read this blog, like many others. If you google "assertThat" you can find many hits.

With the creation of Cotta project, I got a chance to really think hard on simple file operations and tests to see how I can make the API as polite as possible, and I think I have found a good answer.

With the default JUnit 4 assertion, you still don't get the benefit of a static typed language, in that you have to remember the class to use to create the matcher for a certain type.

So I created a JUnit assertion adapter that will allow you to type

ensure.that(yourValue)

and get the appropriate assertions object based on the type of the object being passed in. The type of the returned object will have just the assertion methods that are applicable to the value.

This also brings an additional benefit. For example, you can have a list instance and call

ensure.set(list)

and it will automatically convert the list to the set and return the set assertion object.

I have just made a release under the cotta project for general feedback

The simple document page is here: http://cotta.sourceforge.net/assertions.html
and the jar can be downloaded here:https://sourceforge.net/project/showfiles.php?group_id=171037

Phoenix First Two XP Sprints

Phoenix has finished its Sprint 5 and 6, which are the first two XP Sprints.

An XP team always goes through four stages, "forming, storming, norming, performing". The first Sprint felt like a storming stage, where we are trying to figure out the best way to get the code in without spending too much time on upfront design. At the same time, we are also getting used to paired programming.

Even though paired-programming has become an old trick for me, I still feel that my pairing skill has gotten worse during the past three years of working solo. The second Sprint felt a lot better, and I am hoping to keep this trend.

Items that worth noting:

• We modified the lava lamp to have a green light on when everything is good. Even though it is redundant, it has very positive effect among us. The only thing we might need to watch out is that someone mentioned that they could be fire hazard because the lamp gets very hot at the end of the day. So we are going to turn them off by the end of the day. This is when I found out that the X10 remote controller does not work, so they are back for replacement now.
• The lava lamps are helping us getting on the habit of treating broken tests as the highest priority. Due to the nature of Phoenix, we got some interesting test breakage already. We got tests that only break on the server, tests that only break on Linux, and a test that hung. One interesting discovery is that each time we are forced to figure out what is wrong and fix them, our tests ended up making better sense and being more like behavior driven, and I was planning on settling for hacks to keep the test passing!
• At the beginning of the project, we chose to create just enough stories to get us through the first Sprint, then created a few more for the second Sprint. Looking back, I think that is a good choice. The kind of stories that we create now are so much different but better from the earlier ones. I think that is because at the beginning, your system has literally nothing. It would take a very good story writer to come up with a list stories that really fit into the "INVEST" category of the story. I am not saying it is impossible, I just think that two Sprints of bad stories is not a bad price to pay to get the ball rolling as early as possible and avoid lots of hassle to learn and teach and debate about good stories vs bad stories.
  

Lava Lamp with CruiseControl

As we are getting Phoenix project under way, I am trying to get it started right by introducing more XP practices. The first three things that we are trying to do are Paired-Programming, Test-Driven Development, Continuous Integration.

Actually, Guidewire has already built an internal tool, ToolsHarness, to handle continuous integration, as I have written in "Managing Tests with ToolsHarness, Individually". The only difference that I want to introduce for Phoenix project is to fix broken tests AS SOON AS POSSIBLE.

What this means is that I want the testing status of our branch to show right in out faces, without us having to launch a browser, so that we know to take action the moment a test is broken.

I talked to the developer who manages ToolsHarness, and he wrote a servlet that serves information about broken tests and test status like this picture, except in one HTTP GET. Then I set up CruiseControl(version 2.8.2) with X10 publisher, following the setup described on this blog post "Bubble, Bubble, Build's In Trouble".

One thing about the normal lava lamp setup has always bugged me in the past, which is when the continuous integration server is in the "testing" state. When you have test broken, the red lava lamp will be on, and you just have to remind yourself that the fix is in and test is running. In some projects, I have used "project soundscape", so that when tests finishe but are still broken, you will know about it. But if you happen to step outside, you will miss it. Or if you just came in, you have to check the browser or ask others.

So this time, I have done it a little differently, taking advantage of the fact that CruiseControl is not the process running the tests. I bought two lava lamp, one kind of in the red color and the other in blue. I set it up so that when there are two independent lava lamps:

• Red Lava Lamp for broken tests: When there are broken tests, it will be on, otherwise, it will be off
• Blue Lava Lamp for testing status: When there are tests running, it will be on, otherwise it will be off

In this way, you have four state to display:

• Neither is on: All tests pass and the tests are up-to-date
• Blue is on and red is off: All tests pass so far, but there are tests running against newer changes
• Blue is off and red is on (see below): You have broken tests, and no code checked in to fix it
• Both blue and red are on (see below): You have broken tests and someone has cheked in new code (hopefully to fix it)
  

The setup is pretty straightforward, except CruiseControl 2.8.2 release is missing two crucial files, "lib/win32com.dll" and "lib/javax.comm.properties", for X10 publisher to work. That, and me missing a tiny but also crucial detail in the documentation, caused my three-hour-hair-pulling experience, and that was with Jeffrey coming to rescue through GTalk. I am going to submit the patch for the release script to include those two files, and documentation with the following checklist:

• You should provide all FOUR attributes related to X10 for the element, so that you are aware of them and make sure they are correct. These four attributes are as following:
  
  • "houseCode" and "deviceCode" are for X10 module configuration.
  
  
  • "port", with the value of COM1, COM2, etc., to match the place you plugin the COM module.
  
  
  • The last one is "interfaceModel", which you should really double check with the COM module that you have.


• Make sure "javax.comm.properties" is in your CruiseControl lib directory (should be there after 2.8.3)
• Make sure you copy "win32com.dll" from CruiseControl lib directory (should be there after 2.8.3) to your Java bin directory
  

In the end, I would like to say that I am a satisfied ci-guys customer!

Greate Article on Pair-Programming

All I can say is that this article says EXACTLY how I feel.

http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/

One thing to add is James Shore's Programmer Man's Theme Song (see end of the post)

JIRA Story Wall

With the "shared dashboard" feature of JIRA, we have been experimenting a shared dashboard that can be served as a virtual story wall that can be useful to us. And here is one version.

AF stories are in the form of JIRA items, in this way, JIRAs created by other teams for bug fixese or support can be rolled into one backlog. Creating stories in the form of JIRA is not nearly as trivial and easy as creating stories on the index cards. But once you pass that phase and get yourself used to it, it does bring a lot of benefits of a digital media.

On the left, the first section shows the stories for the current Sprint with status and the person who is working on them. Each person is to finish the JIRAs assigned to him or her, before picking the ones assigned to the general bucket (AF General).

The section section shows the stories allocated for the next Sprint, grouped by assignees and components. The third section shows the full current backlog by component and priority. We used it a lot when trying to figure out what to work on next or what to push to next release. The last one is the backlog for the next milestone.

During the Sprint, some issues will come up. The most urgent ones will be pulled into the current Sprint to be dealt with right away. The others will either be added to the next Sprint, or add to the appropriate backlog. At the beginning of the Sprint, after counting the JIRAs already added to the Sprint, carrying over the ones from the past Sprint, we will select more JIRAs from the backlog by looking through the components.

On the right, the first section is the list of the JIRAs that the current user is working on (In Progress). It has been pretty useful to me to come in and get started right away by looking at this short list. However, I just learned today that everybody else is just looking at the JIRAs assigned to him or her in the current Sprint.

The JIRAs in the next list are the ones that have been marked as resolved by developers but not verified by QA. They are sorted based on the order that QAs would like to process them. QA team uses this to pick the JIRAs to verify during the Sprint.

The last section on the right contains the JIRAs that have not been added to any backlog. In this way, all the JIRAs will be looked at before adding to the backlog. One thing about using JIRA as story is that anyone can create a JIRA and assign it to your team, which mean your backlog can grow without you knowing it. With this extra step of adding newly created JIRA to the appropriate backlog, we are always aware of any new work coming our way.

Burn-up and Burn-down Charts

I have always thought Sprint reporting is a major communication tool to be used within the team as well as to the outside. It is the time for the team to take one step back, look at the project as a whole, comparing notes, and make continuous improvements. It is also the time for the team to report the progress and any difficulties encountered, so that the stake holders can make plan adjustments and provide help if needed.

Burn-up and burn-down charts are my favorite report, because they fit very well in the story based iteration model of the project development. Anyone understanding stories and iterations (not that it is always easy to learn) can understand these charts very easily. I also find that these chart can generate more questions and lead the team in the right direction.

Burn-down Chart

Burn-down chart is straightforward and easy to understand. It measures the burn rate of the story in the unit of the story points. It is really easy to understand different ways of predicting the outcome of the project by predicting the future velocity of the Sprints.

All the iteration tracking tools that I have tried have this support. This one is made by Pivotal Tracker.

For those who use JIRA or good-old story cards to track the iterations, it is not hard to produce this chart as well, with the worst part being figuring out where to use what formula. The following are from the other two projects, made with Microsoft Excel and Google spreadsheet. With customized tool, I get to explore different styles.

In the first one, the stories are divided into "must-have" and "everything else" category, and tracked at the same time. The prediction lines are shown in different color. In the second one, the progress is shown along with the burn-down, so that in the case where it is actually "burning up", it shows that it is not caused by losing velocity.

Burn-up Chart

For a project with just a single coach, burn-up chart can be a great help. It can explain a lot of concepts in the story based development, iterative development, and can help the coach recognize the patterns in the development and take actions to adjust the direction of the team.

I have found that burn-up chart always a bit harder to understand, and might look intimidating. So if you are introducing it for the first time, you should not just paste it in a report and email to others. It is best to show it in person and let the conversation start.

The first chart shows a project where development is fairly smooth, QA can just keep up with the story being finished. On the other hand, the project requirement is very volatile. The interesting thing to point out is that because the team is focusing on one Sprint at a time during the release, and one story at a time during the Sprint, the dramatic scope changes did not affect the development at all.





The second one is a quite typical burn-up chart, where the team discovers new cases as they go, and adding the understanding to the backlog in the form of the stories.

Sprint Burn-up Chart

I also found a burn-up chart for the Sprint is useful to figure out what happened during the Sprint. I think this is what is called "Sprint Signature" in the SCRUM book.

A Sprint burn-up chart should be used strictly internally, because only the team who have just been through the Sprint can look at it, talk about it and then draw conclusions. This should never be used for managerial purpose, in my humble opinion.