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

Test Driven Development (TDD) - Explained

Test Driven Development (TDD)

Define

Test Driven Development (TDD) is about writing the test first before adding new functionality to the system.

Explain

The cycle at the heart of TDD is:

• Write a test (test fails - RED)
• Write some code to get the test to pass (GREEN)
• REFACTOR the code to be as simple an implementation of the tested features as possible
• Repeat

Agile developers work in this circle of life when adding new code. Write the test first. Make it pass. Then refactor.

Tests provide feedback regarding:

• Whether the system works
• If the system is well-structured

By writing the Test first, we get double the benefit. 

The Exercise of Writing the Tests:

• Makes us clarify the acceptance criteria for the next piece of work - we have to ask ourselves how we can tell when we are done (design)
• Encourages us to write loosely coupled components, so they can easily be tested in isolation and, at higher levels, combined together (design)
• Adds an executable description of what the code does (design)

Running the Tests:

• Detects errors while the context is fresh in our mind (implementation)
• Let us know when we've done enough, discouraging over-loading the code and adding unnecessary features (design)

This feedback cycle can be summed up by the Golden Rule of TDD: "Never write new functionality without a failing test"


Contributors:

"Growing Object-Oriented Software, Guided by Tests" by  Steve Freeman and Nat Pryce

Six Levels of Agile Planning

Six Levels of Agile Planning

Definition

One of the misconceptions is that agile process doesn't do enough planning. In reality, Agile does lot more planning and risk mitigation than traditional processes. Agile focuses on planning very often instead of doing comprehensive and assumption based planning once. Agile Planning (a.k.a. planning onion) has 6 levels - Strategy, Portfolio, Release, Iteration, Daily, and Continuous.

Think of Agile planning a layers of an onion. We peel them back one a time to give you a thorough understanding about how to perform each step.

Agile Planning Onion Layers

1. Strategy
2. Portfolio
3. Release
4. Iteration
5. Daily
6. Continuous

Agile Strategy Planning

Projects and product development efforts ideally start with a vision associated with a business need or direction. This vision is then typically framed in context of a strategy and associated goals and objectives during a management team planning session. Strategy is the creation of a unique and valuable position, involving a different set of activities and it involves making choices throughout the value chain that are interdependent.

Agile Portfolio Planning

Goal of portfolio management (strategy execution) is to minimize value evaporation and maximize value retention. Strategy creates value but some of it evaporates due to poor execution and other organizational frictions. To understand Value Evaporation, assume that the strategy is right and, therefore, value creating. Thus, if there is any loss in value due to a poor strategy, it is not a part of Value Evaporation.

A good agile strategy cannot prevent the evaporation of value. Think of a tropical village that is perpetually short of water. So, the villagers come up with a strategy. It involves digging a big hole in the ground to create a reservoir of water from natural rain. The strategy works. The reservoir fills up. But the villagers forgot how mercilessly hot the tropical sun can be. The reservoir did not last very long. Evaporation returned its water to the atmosphere. For the villagers, what matters is not just how much water was there in the reservoir initially, but how much is retained after evaporation. 

The same is true for any organization. Its goal is to come up with a strategy that maximizes value retention by incremental and mutually reinforcing execution of value chain. Key for value retention is to manage portfolio by inspecting and adapting in small increments to utilize feedback from internal and external customers.

Agile Release Planning

Release planning is the third layer of Agile Planning Onion. Releases represent the large-grained delivery cycle in agile development. Releases typically range between one and six months, but may extend longer in some environments. Key for agile release planning is to continuously add value in small increments to utilize feedback from internal and external customers. Following diagram depicts how traditional execution differs from agile execution. In traditional execution, value is stacked and only delivered in the end. On the contrary, agile execution creates continuous value chains driven by agile portfolio management.

Releases begin with a release planning meeting where product owners (or product managers, project leads, etc.) work to define and prioritize a candidate set of features that are then estimated by the team.

Agile Iteration Planning

Iteration planning is the fourth layer of Agile Planning Onion. Also known as Sprints, iterations are short, fixed-length subsets of releases, generally in the 1-4 week time frame. Iterations represent the execution heartbeat of the project. During each iteration the team's goal is to deliver potentially shippable software. 

Iterations incorporate three key phases:

1. Ready (backlog grooming, iteration planning)
2. Remove impediments throughout the execution (daily standup meeting)
3. Done - usually agreed by the team as a definition of done (iteration review and retrospective)

Agile Daily Planning

This is the fifth layer of Agile Planning Onion. Every day the team is focused on completing the highest priority features in the form of working, tested software. As features are delivered within the iteration, they are reviewed and accepted, if appropriate, by the product owner. Each day a short, 15-minute stand-up meeting facilitates the communication of individual detailed status and any impediments or issues. Product is integrated and tested on a daily basis. Burndown charts are the key tool for the team to review progress on a daily basis. These charts help teams to take corrective actions quickly. 


Agile Continuous Planning

This is the final and one of the most critical layer of the Agile Planning Onion. Agile product development teams are constantly driving towards a state of continuous, adaptive planning, collaboration, design, development, testing and integration. This commitment fosters a dynamic, highly productive environment in which automation is critical and the output is always high-quality, valuable working software.

Visit Agile, LLC Today

Contributors:

Kanban - In a Nutshell

Kanban - In a Nutshell

Visit Agile, LLC Today

Definition

Kanban is a method for developing software products and processes with an emphasis on just-in-time delivery while not overloading the software developers. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and developers pull work from a queue.

Kanban can be divided into two parts:

• Kanban – A visual process management system that tells what to produce, when to produce it, and how much to produce.
• The Kanban method – An approach to incremental, evolutionary process change for organizations.

The Kanban Method

Kanban - Signboard

The name 'Kanban' originates from Japanese, and translates roughly as "signboard". Kanban traces back to the early days of the Toyota production system. Taiichi Onho developed the Kanban system between 1940-1950 to control production between processes and to implement Just In Time (JIT) manufacturing at Toyota manufacturing plants in Japan. The Kanban method as formulated by David J. Anderson is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. One example of such a pull system, is a Kanban system, and it is after this popular form of a work-in-progress, limited pull system that the method is named.

The Kanban method is rooted in these basic principles:

Start with what you do now

• The Kanban method does not prescribe a specific set of roles or process steps. 
• There is no such thing as the Kanban software development process or the Kanban project management method. 
• The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system.

Agree to pursue incremental, evolutionary change

• The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. 
• Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. 
• The Kanban method encourages continuous small incremental and evolutionary changes to your current system.

Respect the current process, roles, responsibilities and titles

• It is likely that the organization currently has some elements that work acceptably and are worth preserving. 
• We must also seek to drive out fear in order to facilitate future change. 
• By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban initiative. 
• Perhaps presenting Kanban against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.

Leadership at All Levels

Acts of leadership at all levels in the organisation from individual contributors to senior management should be encouraged.

Six Core Practices

Anderson identified five core properties that had been observed in each successful implementation of the Kanban method. They were later relabeled as practices and extended with the addition of a sixth.

Visualize

• The workflow of knowledge work is inherently invisible. Visualizing the flow of work and making it visible is core to understanding how work proceeds. Without understanding the workflow, making the right changes is harder.
• A common way to visualize the workflow is to use a card wall with cards and columns. The columns on the card wall representing the different states or steps in the workflow.

Limit WIP

• Limiting work-in-process implies that a pull system is implemented on parts or all of the workflow. The pull system will act as one of the main stimuli for continuous, incremental and evolutionary changes to your system.
• The pull system can be implemented as a Kanban system. The critical elements are that work-in-process at each state in the workflow is limited and that new work is “pulled” into the new information discovery activity when there is available capacity within the local WIP limit.

Manage Flow

• The flow of work through each state in the workflow should be monitored, measured and reported. 
• By actively managing the flow the continuous, incremental and evolutionary changes to the system can be evaluated to have positive or negative effects on the system.

Make Policies Explicit

• Until the mechanism of a process is made explicit it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. 
• With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.

Implement Feedback Loops

• Collaboration to review flow of work and demand versus capability measures, metrics and indicators coupled with anecdotal narrative explaining notable events is vital to enabling evolutionary change. 
• Organizations that have not implemented the second level of feedback - the operations review - have generally not seen process improvements beyond a localized team level. As a result, they have not realized the full benefits of Kanban observed elsewhere.

Improve Collaboratively, Evolve Experimentally

• The Kanban method encourages small continuous, incremental and evolutionary changes that stick. 
• When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus.
• The Kanban method suggests that a scientific approach is used to implement continuous, incremental and evolutionary changes. The method does not prescribe a specific scientific method to use.

Contributors:

Scrum - In a Nutshell

Scrum - In a Nutshell

Visit Agile, LLC Today

Definition

Scrum Is an Innovative Approach to Getting Work Done

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.

The Scrum Framework in 30 Seconds

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wishlist, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Scrum - A Thorough Description

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Scrum focuses on project management institutions where it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loops that constitute the core management technique are used as opposed to traditional command-and-control management. Its approach to planning and managing projects is by bringing decision-making authority to the level of operation properties and certainties.

Core Roles

The core roles are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project). They represent the scrum team.

Product Owner

The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the development team, it is recommended that this role not be combined with that of ScrumMaster.

ScrumMaster

Scrum is facilitated by a ScrumMaster who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the Development Team and keep it focused on the tasks at hand. The role has also been referred to as a servant-leader to reinforce these dual perspectives.

The ScrumMaster differs from a Project Manager in that the latter may have people management responsibilities unrelated to the role of ScrumMaster. The Scrum Master role excludes any such additional people responsibilities.

Development Team

The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing, even though they may interface with project management organizations (PMOs).

Ancillary Roles

The ancillary roles in Scrum teams are those with no formal role and infrequent involvement in the Scrum process - but nonetheless, they must be taken into account.

Stakeholders

The stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefit[s] that justify its production. They are only directly involved in the process during the sprint reviews.

Managers

People who control the environment.

Sprint

A sprint is the basic unit of development in Scrum. The sprint is a "timeboxed" effort, i.e. it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month.

Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

During each sprint, the team creates finished portions of a product. The set of features that go into a sprint come from the product backlog, which is an ordered list of requirements. Which backlog items go into the sprint (the sprint goals) is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed (the ones with the highest priority). The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog. The sprint backlog is property of the development team, i.e. during a sprint, no one is allowed to edit the sprint backlog except for the development team. The sprint goals should not be changed during the sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

Like other agile development methodologies, Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the sprint backlog. There are also open-source and proprietary packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools, and maintain their artifacts in hard-copy forms such as paper, whiteboards, and sticky notes.

Meetings

Daily Scrum

Each day during the sprint, a project team communication meeting occurs. This is called a daily scrum, or the daily standup. This meeting has specific guidelines:

• All members of the development Team come prepared with the updates for the meeting
• The meeting starts precisely on time even if some development team members are missing
• The meeting should happen at the same location and same time every day
• The meeting length is set (timeboxed) to 15 minutes
• All are welcome, but normally only the core roles speak

During the meeting, each team member answers three questions:

• What have you done since yesterday?
• What are you planning to do today?
• Any impediments/stumbling blocks?

Any impediment/stumbling block identified in this meeting is documented by the ScrumMaster and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.

Backlog Grooming

The team should spend time during a sprint doing product backlog grooming. This is the process of estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking larger stories into smaller stories.

• Meetings should not be longer than an hour
• Meeting does not include breaking stories into tasks
• The team can decide how many meetings are needed per week

Scrum of Scrums

• Each day normally after the Daily Scrum (larger companies can choose to have these once per week)
• These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
• A designated person from each team attends.

The agenda will be the same as the Daily Scrum, plus the following four questions:

• What has your team done since we last met?
• What will your team do before we meet again?
• Is anything slowing your team down or getting in their way?
• Are you about to put something in another team’s way?

Sprint Planning Meeting

At the beginning of the sprint cycle (every 7–30 days), a “Sprint planning meeting” is held.

• Select what work is to be done
• Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
• Identify and communicate how much of the work is likely to be done during the current sprint

Eight-Hour Time Limit:

• (1st four hours) Entire team: Dialog for prioritizing the Product Backlog
• (2nd four hours) Development Team: Hashing out a plan for the Sprint, resulting in the Sprint Backlog

At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”

Sprint Review Meeting

• Review the work that was completed and not completed
• Present the completed work to the stakeholders (a.k.a. “the demo”)
• Incomplete work cannot be demonstrated

Sprint Retrospective

• All team members reflect on the past sprint
• Make continuous process improvements

Two main questions are asked in the sprint retrospective: 

• What went well during the sprint? 
• What could be improved in the next sprint?

Artifacts

Product Backlog

The product backlog is an ordered list of "requirements" that is maintained for a product. It contains Product Backlog Items that are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. The features added to the backlog are commonly written in story format. The product backlog is the “What” that will be built, sorted in the relative order it should be built in. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the stories on the backlog for the Development Team. The product backlog contains rough estimates of both business value and development effort, these values are often stated in story points using a rounded Fibonacci sequence. Those estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return on Investment) is higher.

The Product Backlog, and business value of each listed item is the responsibility of the Product Owner. The estimated effort to complete each backlog item is, however, determined by the Development Team. The team contributes by estimating Items and User-Stories, either in Story-points or in estimated hours.

Sprint Backlog

The sprint backlog is the list of work the Development Team must address during the next sprint. The list is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. This is done by the Development Team asking "Can we also do this?" and adding stories/features to the sprint backlog. The Development Team should keep in mind the velocity of its previous Sprints (total story points completed from each of the last sprints stories) when selecting stories/features for the new sprint, and use this number as a guide line of how much "effort" they can complete.

The stories/features are broken down into tasks by the Development Team, which, as a best practice, should normally be between four and sixteen hours of work. With this level of detail the Development Team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed during the daily scrum, according to the set priority and the Development Team member skills. This promotes self-organization of the Development Team, and developer buy-in.

The sprint backlog is the property of the Development Team, and all included estimates are provided by the Development Team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.

Contributors: