Why is your team doing Scrum? Check the appropriate box below.

Somebody's boss someplace said we have to do Agile now.
Agile sounded like a good thing to have on my resume.
Our software has problems and Agile is the magic bullet solution.
Our team wants to get better at quality software delivery and estimation.

Those of you who chose the last option, keep reading. Everyone else, please click HERE.

We do Scrum because the process yields better results. We do it because we want people to think and be empowered as a team, rather than just being told what to do. We want our software to please our customers. We want to please our customers regularly and often. We want to be able to respond to changes in direction, changes in requirements, or just change in general - in a positive way and continue to deliver useful software. We like the notion of teamwork and collective ownership. We like collaboration. We like to get feedback often, and integrate it into our process so we get better, faster. We measure our success and progress only in terms of delivered, working software.

Scrum is more than a process for managing projects, it is a change in mindset. Just deciding to do mini-waterfalls in 4-week cycles isn't Scrum. And it isn't very useful or productive either. [BTW just so we're clear: A mini-waterfall looks like a 4-week "sprint" where the first week is design and specification generation, two weeks are coding, and the last week is testing and bug fixing.]

It takes a mind shift to a willingness to be a TEAM rather than just a bunch of people working on the same project. There IS a difference. Without an attitude of cooperation and collaboration, Scrum will not succeed (nor will any approach really), and Scrum will just seem to be an additional burden to those forced into it.

Don't mandate that your team adopt Scrum. Explain to them why it's better. (At this point I should probably mention that YOU should understand why it's better...) Convince them. If they aren't convinced, keep at it until they are. If they are skeptical, that's OK but they need to be open-minded enough to actually try it for a while. If they aren't truly open-minded, or can't be convinced - DON'T DO SCRUM. This kind of a process needs to have WILLING participants that are cooperative. It's not for everyone. Be prepared for the fact that some people just don't get it, or WON'T get it. They really need to find a different team to work on. Don't burden those on a Scrum team with members who don't want to be there.

Scrum is not a silver bullet. It's not always the answer, but it is ONE answer. Educate your team. Be supportive, and explain why the tenets of the Agile Manifesto and the twelve principles behind it are a good idea and that they can really work in your organization.

More advice. Have a Scrum master. This person should be trained in the role and understand it. Have a true Product Owner (NOT the Scrum master by the way) who represents [ALL] of the stakeholders. Make sure they really do identify and represent the real stakeholders, and have the authority to prioritize. Hire a Scrum consultant, or bring in an experienced person who has helped teams get up to speed on Scrum - and LISTEN TO THEM. Don't pick and choose which pieces of Scrum you like at first, just do them all "by the book." You can fine-tune your process in response to sprint retrospectives later.

Scrum can be a great way to develop software, or it can feel like a horrible burden. It all depends on the attitude and openness of the team doing the process. Make sure you make your experience the former instead of the latter.

Here is a kind of step-by-step guide to doing pair programming. If your team doesn’t adopt any other principles of XP or lean, this is the one thing that will give the greatest benefit for adoption. This is a good recipe for ROI++.

 

Attitudes

In my experience, programmers are the least willing of all professionals in the software development industry to be paired up on tasks. For some reason, we developers seem to have attitudes and fears about this mode of work. I have heard attitudes expressed like "I don't want someone to be nitpicking every character I type," "I dont want to share my keyboard." There are also un-spoken fears that I have heard told: "They might find out that I'm not as smart as they think I am," "the other guy might make me look stupid," and "I don't want them to know how I really write code." These attitudes and fears are the number one barrier to doing pair programming.

 

C4 Requirements Checklist

For people to be able to do pair programming, I suggest the following readiness checklist to determine if someone is ready. Not everyone is at a point where pairing makes sense for them. When creating a team to do pairing, it is important that everyone have an open mind to trying the process. Give the list to the people and let them do it on their own, and decide for themselves. Don't collect their lists, just their yes or no answer.

 

1. Am I willing to Cooperate – do I really want to do this or is someone just telling me I have to do it? Am I bought-in to the idea or is it being forced on me?
2. Am I willing to Collaborate – can I work together with others in a team environment where we all pitch in together to accomplish a task, or do I need to do things only by myself to be successful?
3. Am I willing to Communicate – can I tell my team mates what I am thinking? Can I get a point across verbally? Can I take a spontaneous thought and talk it through verbally and get someone else to understand me? Am I willing to work toward these goals if I’m not quite there yet?
4. Am I willing to Create – can I be of a mind-set that I am creating something of value regardless of the process, and am I willing to try something new to accomplish this?

 

Implementing It

If your team is on-board with the C4 checklist, congratulations! You now are able to start off on a wonderful process of building some great software. My suggestion now is to get some resources together. Here’s a starting recommendation.

 

1. Pair Working Space

1. The team should ideally have a smallish space to do their pair programming work. This should be separate from offices or cubicles. While this is not always possible, I have seen some great creativity used to put the team together in their own space. Sometimes this means just adopting a round meeting table in the middle of a cube farm. Whatever it means for your team, do establish the pair working space. Use the guideline of 6-8 square feet per person, and keep the team size under 10.
1. Desks, chairs
1. One desk for every two people, and one chair per person, with one extra chair is just about perfect. Don’t have the desks more than a few feet apart. Keep the team together in a smallish space. This will greatly aid cross-communication between pairs while development is happening.
2. Machines
1. One development machine per desk. Two team members will be sharing one machine.
3. Monitors, Keyboards, Mice
1. Two of each per desk. Space them two feet apart so that people can have a little personal space. Connect both monitors to the dual-head video card, and clone the display so both have the same image. Use USB keyboards and mice, and place one each in front of each monitor.

 

Orienting the Team to Pairing

Be sure to orient your team to this kind of thing first. Let them know that they will be expected to work together on one machine sharing control, but that each will have their own keyboard, monitor, and mouse. Remind them that cooperation and verbal communication is essential when working with a partner.

 

Hours and Etiquette

When working closely with other people in this way, we need to be polite, focused, and productive. There are times for all of us when we just aren’t all three of these, and that’s OK – it’s just human nature. We need to be able to “check out” and go elsewhere if that’s the case for anyone at a given time. [Assuming a standard 8AM-5PM day…] Start pairing at 10am, take lunch at noon, and stop by 3PM. This gives everyone some time to work on other things or take meetings outside of pairing. Adjust times accordingly for your team, but this is a good starting point. Don’t make the mistake of thinking your team can pair for 8 hours a day. A 5 or 6 hour pairing day is a lot, even for an experienced team.

 

Challenges

At first, there may be personality challenges. Some people are more easily able to communicate and share control. Don’t worry if the first few days are a bit rocky, this actually can be a good learning experience (as long as nobody blows up). Keep an eye on tempers to make sure that hot situations can be defused before they cause problems. One technique that works well is to switch pairing partners at the middle of the day, or at least every day. This gets people new learning experiences and moves knowledge around the team (another great benefit).

 

There is one specific challenge that I want to bring up, because on a pairing team it can be a real issue. Everyone should wash their hands. A lot. We shouldn’t have to remind people to wash after visiting the bathroom, but DO it anyway. I encourage and ask people to use hand sanitizer before touching the keyboard at my workstation. Bugs have really gotten nasty out there, if you haven’t noticed. If there is an illness, be sure to make the people stay at home, or a single cold or flu can wipe out all development pretty fast. I recommend spending $2 for a small bottle of hand sanitizer for every workstation and placing it in plain sight.

 

Benefits

• Team knowledge share
1. Knowledge will naturally migrate through the team, since people working together will share knowledge about a task. Rotating people through tasks is a fantastic way to raise product knowledge and awareness for a low cost.
• Better code
1. Two pair of eyes on a piece of code are always better than one pair. We sometimes call this process “real-time code review.” Mistakes are simply caught far, far sooner. Code mistakes and poor design decisions simply just evaporate as two people think about the code as it’s being written.
• Quicker code
1. Not that it executes faster, but it probably will do that too. A pair can produce a solution to a feature request far faster than a single developer in almost all cases I have seen, and every study I have ever read. It’s not half the time, but it’s probably more like 2/3 (a 33% speed improvement for you percentage folks…)
• Tight-knit team
1. The team will be more integrated, stick together, be more cohesive, and more social together. People on a pairing team will be united for the delivery of a product, and it the experience will form bonds between team members.
• High-performance team
1. Pair programming teams will almost always outperform teams that don’t use this technique. The more experience teams get to have with pairing will yield even higher performance results.
• Higher morale
1. Teams that use pair programming are almost always happier, and more positive about their working experience.

Summary

When we find the people who have an open mind, and are committed to success as a team, we have a great asset to leverage to write good software. Using the technique of pair programming in a shared workspace, we have many benefits for all - the company, the team, and most importantly, the customer. It takes a little work to get to a high-performance team, but it really isn’t much, and in my opinion, easier than finding a way to coax performance from a non-paired team.

 

If you have any input or feedback on this article, I welcome it – please post a comment below.

Please join us at the September Agile Beer Night, at the Celtic Bayou in Redmond, from 5PM to 7 (or whenever). Looks to be a pretty good turnout this time. We'll have someone say a few words for starters on topics of conversation, and of course there will be beer...

Please stay tuned to the blog for the Agile Beer User's Group at http://AgileBUG.com

Acceptance criteria are the key to making sure our stories are done, and have as few bugs as possible. When the criteria are weak, not complete, unclear or misunderstood, this can be the root of a whole host of problems. Acceptance criteria are a critical point on which a team can focus to improve their results and delivery.

Acceptance criteria can be implemented as automated acceptance tests. The PO, the Developers, and the QA people on the team should all be in agreement that the acceptance tests do illustrate that the software works as desired.

I wrote another article with more thoughts on acceptance criteria, in a recent post on the TestDrivenDeveloper.com blog site, please check it out!

Acceptance criteria can be a tricky bit, especially if the customer and the team don't have much experience at generating and capturing them. I would definitely consider it a process smell if I saw a continuing pattern of low quality acceptance criteria. Really this can kill a project if left untended to fester on its own.

From what I have seen on several teams, we should all focus more time and effort on acceptance criteria gathering and then automating it in the sprint as part of the criteria for Done.

If you have mechanisms or practices that enhance or enable better collection or identification of acceptance criteria, please post a comment below.

"As a user, I can select my preferences and save them

so that the program will do the right thing."

ahem...

Sometimes we in the software business need to realize that the people using our software are not experts in the field. We must become experts at understanding the requirements and implications of the domain for which we write software, but we can not expect our users to do the same. We must be able to make some decisions with the software so that it does the "right thing" for the user. In today's world, software users have little time to fiddle with settings or options. They just need the software to do a job for them and do it the right way the first time. Our impatient "get it now" society of users definitely has this attitude. If our software doesn't do what they need it to do, they will more likely abandon it for something else before attempting to fiddle with settings, parameters, options, and preferences.

Our product owners need to be keenly aware of this attitude, and get the balance right with the features and stories that the customer base needs. While this is not an easy task, it is a very important one. As our software gets smarter and smarter, it should be more aware of what the user is attempting to accomplish, and it should make some decisions and assumptions based on the mode of intent. In addition (here is the key point missing from most software today) we need to *tell* the user what the mode is, and what the assumptions are. If we got it wrong, or the user wanted something else, then s/he has the opportunity to change the operating mode before the software attempts to do the "wrong" thing.

A "mode" could be an entire slate of preference settings, that come packaged out of the box with the defaults set for performing a specific task, or scenario. This entire slate could be modified if the user is advanced and cares to fiddle with them, but having the entire slate saved as a set, that could be chosen as a very simple selection. Then, always make it clear what the system operating mode is, and how to change it.

Keep it simple by being smart about what the user is trying to accomplish and make some decisions. Select the most appropriate mode, then - most importantly - communicate those decisions to the user, and let them know what the software is assuming about the task they are trying to perform. Give the user choices about how to control the software, and change its mode, but keep the goal to be helping the user stay more focused on performing the task at hand.

"Obviously, Development should be responsible for the acceptance tests. The developers are the ones on the team who are the best at writing good code. The developers are best able to turn the acceptance criteria into valid executable specifications. Development then can use the automated acceptance tests to drive the development TDD cycle."

"In QA, we never totally trust the developers. We do trust them to do the right thing. However, we have a saying in QA - Trust but Verify. QA should be responsible for the acceptance tests. At the end of the day, it is our job to make sure that the software meets the criteria for acceptance, so it's really a QA ballpark. Dev's should focus on unit tests."

Two strong opinions, and really I think both are right. Development should be using acceptance tests to drive an ATDD cycle. Developers are (usually) better at writing code than SDETs, so they do a more efficient job on acceptance tests. But QA probably has a more even overall view of the software, and from a different and more independent perspective, so they should be writing the acceptance tests as well as the other test automation. QA also has the responsibility of signing off on the code, so they should be writing the acceptance tests.

So, this may be one way to resolve the issue. Have developers and testers both work on automated acceptance tests for the first story. When the tests are completed, developers are free to begin working on the unit tests and code to satisfy the acceptance tests. QA can then begin test case generation and automation implementation.

I believe that this solution is the best of both worlds, because Development and QA will be completely in sync and on the same page for all of the stories where the acceptance tests are co-developed. There won't be any ambiguity on whether the software meets criteria, and both teams will be in agreement as to what is passing and what isn't. The tests will be well-written, and they will run as efficiently and accurately as possible. They will be written with multiple perspectives - the customer (who supplied the acceptance criteria), QA who makes sure that the test accurately guarantees the outcome, and Development, who makes automation quicker to implement and more efficient.

With automated acceptance tests co-written by dev and test, we have a great common point of communication, and a good example of how teamwork can really help software shine and inspire confidence and trust in the eye of the customer.

I have posted the acceptance test code in both Selenium and WatiN on the AgileBUG.com site. This code is a short demo and example of how we can do acceptance testing using both tools. The presentation is a short one on what ATDD is, and why we should do it. It serves as a prelude to the tools demo.

Join us at the Owl and Thistle tonight in person for a pint and some good agile discussions!

The UW Extension for Professional Development and Continuing Education now has a Certificate Program in Agile Development. It's being taught by some guys I used to work with first-hand, so I happen to know they are all pretty good at Agile Development. They are certainly highly qualified, and this certification course is a good opportunity for those folks who may not be as familiar with Agile principles to get some good instruction on how to do it well. Be sure to apply now, as this course is likely to fill fast.