Pair Programming - Explained

Pair Programming - Explained

Two is better than one!

Pair Programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the tactical aspects of completing the current task, using the observer as a safety net and guide.

If the driver hits a problem, there are two people to find a solution, and one of the two usually has a good idea.

It is so easy, a baby can do it.

Other advantages include the fact that where two people have differing specialities, these skills are transferred. Ad-hoc training occurs as one person shows the other some tricks, nice workarounds, etcetera.

The end result is that both developers are fully aware of the code, how it works, and why it was done that way. Chances are the code is better than one developer working alone, as there was somebody watching. It's less likely to contain bugs and hacks and things that cause maintenance problems later.

In a bigger team, the pairing can change each week so each team member is partnered with somebody different. This is a huge advantage, as it gets developers talking and communicating ideas in the common language of code.

We found this to be as fast as working separately. The code got written quicker and didn't require revisiting. And when it did need to change, more than one person was familiar with the code.


Contributors:

Avoidance of Accountability - The Death Knell of Teamwork

Avoidance of Accountability

Track and Analyze

When a company first decides to initiate change and move towards the Agile methodology, it is inevitable that grumblings about it being yet another process change raise to the surface.

Companies that choose to use the Scrum framework within Agile face a similar situation.  This usually arises from what the developers feel is management watching them more closely.  This stems from the insistence of gathering metrics from the developers, i.e. daily hour reporting – or the like.

Their first instinct is to fear that management will be looking at the individual performance of the developers.  A hurdle faced by an Agile Coach and Scrum Master is to alleviate this fear.  Even though the matrices are there for management to do just that, I have yet to see the numbers used in that fashion.

They are watching me!

I was asked once if I could provide such numbers to management, I said I could but I explained that the numbers would be entirely out of context.  When asked to explain I indicated that the numbers will be a black and white description of hours worked only.  I went on to say that the work performed by individuals is quite different from developer to developer.  Developer A and B can indeed be developers that can devote 100% of their time to development.  But developer B is an SME and spends a good portion of the day helping other developers or attending meeting to help support development.  Most developers fall into some varying degree of time allotment spent on other tasks not directly associated with the current Sprint. Therefore it would be negligent to compare one developer to another.

Back to accountability.  Even though the developer’s fear of being tracked more closely is unfounded, the avoidance of accountability is very real.  In Patrick Lencioni’s book, The Five Dysfunctions of a Team, he explains that the team’s "lack of real commitment and buy-in" creates an environment in which the team does not want to be held accountable.  He goes on to say, "without committing to a clear plan of action, even the most focused and driven people often hesitate to call their peers on actions and behaviors that seem counterproductive to the good of the team."

"Just the facts, Ma'am."

It has been my experience that once I can make the teams feel less paranoid about being watched and assuring them the metrics are being used to track team progress, not individual, it becomes easier for them to trust the system.  Over time I show them how the metrics are being used.  For example, the velocity of a team is important.  Without that the team cannot determine how much work to plan for in each Sprint.  Without the Burndown Chart it is hard for the team to know if they are on track during the Sprint.  Finally, without the Burnup Chart is hard for the teams to know if they are completing the work in a timely manner.  Ideally the Burndown and Burnup chart is a mirror image of one another.

Having accountability at all levels is very important.  Do not try to avoid it.

Test Driven Development - Deep Dive

Test Driven Development (TDD) - Deep Dive

Test-driven development (TDD), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.   What is the primary goal of TDD? One view is the goal of TDD is specification and not validation. In other words, it’s one way to think through your requirements or design before your write your functional code (implying that TDD is both an important agile requirements and agile design technique).  Another view is that TDD is a programming technique.  The goal of TDD is to write clean code that works.  I think that there is merit in both arguments, although I lean towards the specification view, but I leave it for you to decide.

The first step is to quickly add a test, basically just enough code to fail.  Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail.  You then update your functional code to make it pass the new tests.  The fourth step is to run your tests again.  If they fail you need to update your functional code and retest.  Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed, turning Test First Development (TFD) into TDD).

TDD completely turns traditional development around. When you first go to implement a new feature, the first question that you ask is whether the existing design is the best design possible that enables you to implement that functionality.  If so, you proceed via a TFD approach.  If not, you refactor it locally to change the portion of the design affected by the new feature, enabling you to add that feature as easy as possible.  As a result you will always be improving the quality of your design, thereby making it easier to work with in the future.

Instead of writing functional code first and then your testing code as an afterthought, if you write it at all, you instead write your test code before your functional code.   Furthermore, you do so in very small steps – one test and a small bit of corresponding functional code at a time.   A programmer taking a TDD approach refuses to write a new function until there is first a test that fails because that function isn’t present.  In fact, they refuse to add even a single line of code until a test exists for it.  Once the test is in place they then do the work required to ensure that the test suite now passes (your new code may break several existing tests as well as the new one).   This sounds simple in principle, but when you are first learning to take a TDD approach it proves require great discipline because it is easy to “slip” and write functional code without first writing a new test.  One of the advantages of pair programming is that your pair helps you to stay on track.

There are two levels of TDD:

1. Acceptance TDD (ATDD).  With ATDD you write a single acceptance test, or behavioral specification depending on your preferred terminology, and then just enough production functionality/code to fulfill that test.  The goal of ATDD is to specify detailed, executable requirements for your solution on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
   
2. Developer TDD. With developer TDD you write a single developer test, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test.  The goal of developer TDD is to specify a detailed, executable design for your solution on a JIT basis.  Developer TDD is often simply called TDD.

Ideally, you'll write a single acceptance test, then to implement the production code required to fulfill that test you'll take a developer TDD approach. This in turn requires you to iterate several times through the write a test, write production code, get it working cycle at the developer TDD level.

Why TDD?

A significant advantage of TDD is that it enables you to take small steps when writing software.  This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps.  For example, assume you add some new functional code, compile, and test it.  Chances are pretty good that your tests will be broken by defects that exist in the new code.  It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.  I generally prefer to add a few new lines of functional code, typically less than ten, before I recompile and rerun my tests.


Contributors:

Our Data is Not Secure - Ever play Angry Birds or Candy Crush Saga?

Our Data is Not Secure

Ever Play Angry Birds?  Your information has been stolen.

Open up any newspaper or news website and you can find stories about the NSA data mining, Google, Facebook, LinkedIn, Yahoo, and Microsoft receiving requests to send information to the our government, and local government agencies snooping into your phones and computers.

Currently, at the olympics in Russia, there is an enormous effort underway to steal data from the people visiting the county which is authorized by the Russian government.

At the olympics, "Russian law allows its intelligence agents to do electronic snooping on anyone inside the country, meaning the phones and personal computers of thousands of foreign visitors, including Americans, are fair game. But even outside of the law, Russian organized crime groups also are well known for hacking smartphones and email for information they use for illicit profit." (ABC News, 2014)

Here at home, "The National Security Agency has secretly broken into the main communications links that connect Yahoo and Google data centers around the world, according to documents obtained from former NSA contractor Edward Snowden and interviews with knowledgeable officials.

By tapping those links, the agency has positioned itself to collect at will from hundreds of millions of user accounts, many of them belonging to Americans. The NSA does not keep everything it collects, but it keeps a lot." (Washington Post, 2014)

"If you're spending hours on your phone playing games like Angry Birds and Candy Crush Saga, or posting online to Google+ and Pinterest, you're probably being spied on. The latest releases from NSA whistle blower Edward Snowden reveal that the National Security Agency, and its UK counterpart, GCHQ, are mining the ad networks utilized in these apps to collect a trove of information on you." (WonderHowTo, 2014)

Even the local government agencies are jumping on board, "Armed with new technologies, including mobile devices that tap into cellphone data in real time, dozens of local and state police agencies are capturing information about thousands of cellphone users at a time, whether they are targets of an investigation or not, according to public records obtained by USA TODAY and Gannett newspapers and TV stations.

The records, from more than 125 police agencies in 33 states, reveal:

About one in four law-enforcement agencies have used a tactic known as a "tower dump," which gives police data about the identity, activity and location of any phone that connects to the targeted cellphone towers over a set span of time, usually an hour or two. A typical dump covers multiple towers, and wireless providers, and can net information from thousands of phones." (USA Today, 2013)

I have been telling my friends about this possibility for years.  Remember this next time you ignore the fine print and agree blindly to the Terms of Use for that cool free app.

Office Politics - Navigating the Political Waters

Office Politics - Navigating the Political Waters

Navigating the Waters

Some people take to office politics naturally. You know the ones who are irresistibly likeable and don't appear to have a manipulative bone in their bodies. They always seem to get people to gladly cooperate on projects. For other folks, actively playing the politics game is uncomfortable and feels inherently insincere. Regardless of which category you fall into, it helps to learn how office politics works. At least it could clear up common misperceptions about the practice and help you reevaluate your own motivations and tactics.

Office Politics

Office politics is at the core of all organizations. Paying attention to it can be just as important as fulfilling the responsibilities written in your job description. If you aren't on the watch for it or don't tactfully engage in it, you could jeopardize your career and watch your hard work and loyalty go down the drain. If this sounds like an exaggeration, consider how things work in your own office. People who get promoted are probably heavily involved in office politics. They often voice suggestions for improvements and make themselves known. Those who consider politics beneath them keep to themselves and appear unfriendly or unmotivated, even if they work hard. When budget cuts are necessary, these people might be the first heads on the chopping block.

A Necessary Evil

Office politics is a necessary evil. With over 20 years in the corporate world I have never seen anyone effectively exclude themselves from office politics. Unfortunately it is a sink or swim scenario.  As much we you would like to exclude ourselves, it is impossible.

Integrity

Avoid Gossip

Maintaining your integrity is a hard proposition when you are mired down in office politics. Avoiding office gossip is the number one way to maintain your integrity. The minute you find yourself dragged into gossip you must pull yourself out graciously. I have been as bold to say that I do not partake in gossip. This works if you know who you are talking to. Saying this to your manager is probably not a good move towards ensuring job longevity.

Office Landmines

Without even knowing, you could be offending your boss, coworkers, or stepping on someone else's toes. When you take over a job, a project or even a nice office that previously belonged to a well-liked coworker, it might foster bitterness and make it harder to work with his allies. Being on the lookout for these issues and addressing them could help you make peace with people you might unintentionally be offending. Indeed, the authors of "Enlightened Office Politics" suggest that you owe it to your company to engage in its politics, because it's the necessary avenue to getting things done.

Climb the Corporate Ladder

The Corporate Ladder

Unless you're an expert office politician, you won't get anywhere unless you've proven yourself to some degree. To climb the corporate ladder, you usually can't rely on empty words and promises, but you must be able to impress the higher-ups with a good reputation backed by solid accomplishments. That's not to say your political skills can't help you do this. In fact, political skill might be the best tool. This is where the alliances you formed with coworkers really pay off. Landing a big account or succeeding at a large project usually requires help from all sides, and if you've done well, you can call your allies into action.


Unfortunately, it's possible no one will notice your accomplishments unless you tell them and remind them. It is suggested that you occasionally brag -- as diplomatically as possible -- about your achievements even when you're not interviewing for an open position. If this seems difficult or even unnatural, try to at least convey how proud you are to have made a difference for the company.

Mastering office politics is not only about climbing the ladder. To me, it is more about earning the respect of my peers. The only way I can be effective at my job is to be able to work with my peers every day. If I don't have credibility at my level, worrying about climbing the corporate ladder is a moot point.



Contributors:

Is it a ScrumMaster weakness, or is there more to it?

Is it a ScrumMaster weakness, or is there more to it?

I have noticed that no two companies utilize Agile in the same way, it is always a hybrid. Such as Agil-fall, Water-gile, Scum-ban, and Agil-icious (Okay, I made that one up).

Slow Erosion

They key to Agile's success is how the ScrumMaster (SM) deals with the variations.  I heard from multiple recruiters that some SMs are rigid in their approach.  This is the letter of law of Scrum and I don't allow for deviation, to paraphrase.  In my opinion, that goes against the very meaning of being agile -  "having a quick resourceful and adaptable character."

This is a slow erosion of Agile principles that needs to be corrected.  If the SM fails to perform at a high level the Scrum framework will collapse under its own weight.

I feel the underlying reason this is happening stems from thinking one can take a 2-day training class and miraculously become an effective ScrumMaster.  

To me, that is like saying once a Medical Doctor (MD) gets certified he is good at what he does.  I don't know about you but I don't want a rookie MD cutting into my body.

I feel it takes at least a year of working in an Agile/Scrum environment before the ScrumMaster can fully understand the system.  It takes even more years to learn the variations.

The Agile methodology is only as strong as the people working within it.  The Product Owner position seems to be understood, but the importance of the SM position continues to be underestimated.

ScrumMasters communicate complex issues to product, stakeholders & developers. They coach engineers. They coach product. They coach executives. They foresee roadblocks and adjust around or plow over them. They report. They manage tools. They define processes. They bust-up ineffective overhead. They empower those around them. They manage (effective) meetings. They lead by example. They ship (damn good) code. They take the blame. They deflect the praise. They listen. They suggest. They rally the troops. They make work fun.


More importantly than all else, however, they seek & speak the truth - regardless of the fallout.


Contributors:

Unscrum Hero