Jon Williams makes the following observation:
Agile development practices require a developer to be social. There’s a daily scrum, pair programming, end-users on team, kaizen meetings and the like, all situations which require high social interaction.
I can agree with that. He then follows with these questions:
(a) Does Agile push developers out of their comfort zone to be more social, OR (b) Did Agile come about because developers want to be more social?
My answer is neither one; for me, context is the deciding factor in my sociability. Like many software engineers, I’m an introvert. Put me in a large group of people whom I don’t know well, and I will clam up and try to escape as soon as possible. But if you put me in a small group of people I know well, I seem like the life of the party.
For this reason, I love working in an agile environment! I’m part of a small team who I know well and trust. I thoroughly enjoy interacting with my team. In fact, at my current job, I’ve taken on the role of social organizer and of helping others to form more personal relationships. My wife finds this role amusing since I’m pretty closed down in many mixed social settings with her.
Some of my unofficial career goals up to this point included: 1.) never being in a position where I had to use PowerPoint on a regular basis, and 2.) spending as little time as possible with sales, marketing and advertising people. In the past, I’ve associated both those activities with pointless waste of time.
Well, since I assumed my new role as QA Architect here at Borland, I’ve violated both those goals. However, the good news is that I don’t feel either one has been a waste of time.
As for PowerPoint, I’m in the role of designing and implementing processes throughout the company, and PowerPoint is one of the tools in the box for that roll-out. Granted, some of the people who attend my presentations may still have my previous association, but I try to make my presentations as short, painless and useful as possible.
And sales and marketing folks. This morning, I spent over two hours in a meeting with representatives from sales, marketing and advertising. That meeting was also not a waste of time for me. Those folks are trying to figure out how to get the word out on how we’ve improved our own software development process (using agile) and changed our own tools to support those changes. I’ve been a big part of that process improvement, so the sales, marketing and advertising people were actually listening to me and others from R&D this morning.
Here’s a problem that I’ve been thinking about recently. I’d love to hear feedback.
Scrum dictates that each user story that a team commits to in a sprint should be complete at the end of the sprint, and the storyâ€™s acceptance criteria define what â€˜doneâ€™ means.
Certain types of enterprise testing can pose challenges to this principle. Performance requirements, for instance, are often based on scenarios that transcend individual user stories.
Here is an example: the application under test supports two different user roles, and the performance requirements stipulate the required performance of individual functions when certain numbers of users of both roles are using the application concurrently. User stories A, B and C cover functionality performed primarily by one user role and stories D, E, and F cover functionality used by another role.
If the team implemented stories A, B and C in one sprint, the team would not fully know whether stories A, B and C meet performance requirements until stories D, E and F are complete and the entire scenario is run with all user roles.
Certainly, the scrum team can minimize these sorts of problems by changing the order in which they implement stories or other strategies. And the team gains a certain amount of value from performing partial tests, but fundamentally, enterprise testing poses these types of challenges, and scrum teams have to deal with them.
If the scrum team cannot work around this sort of challenge, then they should consciously acknowledge the challenge, figure out a compromise to agile principles or scrum practices in order to deal with the challenge, and specify the risks involved in the compromise. And most importantly, all of this should be communicated to the customer at the sprint review.
Using the example above, a portion of the sprint review would go something like this:
Hereâ€™s the challenge we faced: in this sprint we completed stories A, B and C to the best of our ability, but we cannot fully know whether these stories fulfill all performance criteria until we complete stories D, E, and F.
Hereâ€™s the compromise we came to: we have completed these stories to the best of our ability. We did as much as we can, short of the full performance testing scenario, to verify that the stories meet performance acceptance criteria.
Here are the risks involved in this compromise: Itâ€™s possible that the stories do not perform as well as expected in an enterprise deployment. But since the missing variable pertains to unfinished functionality, users will not be executing that functionality at this time anyway.
Hereâ€™s how we plan to address this compromise: we plan to complete stories D, E and F in the next sprint. At that time, weâ€™ll be able to run the entire performance scenario and verify that stories A, B and C meet performance requirements.
At that point, the customer would be able to accept or reject the stories. However, if the team has been working closely with the customer from the beginning of the process, the customer should have known about the challenges and have worked with the team on how to address them. The risks presented at sprint review should not come as a surprise to the customer.