David Hawks, Author at Agile Velocity

Blog

A Tried and True Method for Retrospectives

By: David Hawks | May 10, 2012 | Agile, Article, Scrum

I feel the Retrospective is the most important ceremony, especially for new teams. I am concerned when ScrumMasters boast they can get their Retrospective done in 30 minutes or less. I must ask, “Did your team learn anything? Are they improving? Are they pushing themselves through the Tuckman Model and getting close to becoming a High Performing Team?”

In my experience, new teams need 1.5 – 2 hours for a healthy retrospective. They need time to reflect on the Sprint and fully explore opportunities for improvement. The retrospective is a key ingredient in engaging teams to take ownership of their own process and figuring out how to improve. In this post, I will walk through my standard approach to a Retrospective.

Goal of Retrospectives

It is easy for the team to identify a laundry list of problems, but the team can’t address more than a couple at a time. The goal is to devise 1-3 actionable items the team can change during the next Sprint timeframe. If the team can make a 2% average improvement every two weeks, they would accomplish over 50% improvement on the year. In order to encourage more significant improvements, we also need to help the team have the courage to try some more radical changes.

Set the Tone

When I kick off a retrospective, I want to make sure it is a safe room for the Team. This includes the team members (Pigs), ScrumMaster and Product Owner, but does not include chickens, stakeholders or managers. We also want to defuse negativity. I usually kick things off with a statement like the following:

“We are looking for changes that we the team can change. This is not a blamestorming session (I usually point with my fingers outside the room), this is a chance for us to reflect on what we (pointing at myself) can do better as a team.”

I might also put the Norm Kerth quote up if I think there might be some attacking of individuals:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

When setting the tone, I also like to share our current metrics. Things like:

The Sprint Burndown
Sprint Results (Points planned vs. completed)
Release Burnup to show progress on overall goal

This helps the team review some of the facts around their performance and effectiveness.

Data Collection

The next thing to do is gather some data and insights on the Sprint. The standard way to do this is Start, Stop, Continue. I create three sections on the wall or whiteboard with those titles and have the team come up with as many items as they can in 5-10 minutes. We are looking for:

Things that worked well and the team should Continue
Things that did not work well and the team should Stop
Things that the team did not do and should Start

This exercise should be silent with folks writing individually. This tends to prevent a couple voices from dominating the discussion and get the introverts to participate a little bit more. We want to give the team members time to reflect to themselves on opportunities for improvement and reinforcement.

They should all be writing at the same time with provided Sharpies and Post-it notes. They should write one item per Post-it, which can be put on the wall anytime. Sometimes, the early ones will help others generate ideas, but this is all done silently. The Sharpies are important so that everyone in the room can see what is written on the Post-it. Once I see that no new ideas are being generated, I move on to the next step.

Read for Clarity

I introduce this step by saying:
“Now we want to read through the items to get an understanding of what everyone has written. On this first pass, we just want clarity so we don’t want to get into discussion or debate. If you are unclear of the meaning of what someone wrote, just ask and that person can provide a brief description of their intent and then we will move on to the next item.

Now, who can come up and read one of the columns?”

I have volunteers from the team read the items to foster ownership by the team. As the facilitator, make sure the volunteer is reading slowly enough so participants have enough time to digest. If after a couple have been read and no one has asked to clarify, I typically will ask for one to be clarified so people recognize it is ok to interrupt. Once they have finished one column, I thank them and ask for another volunteer until all three columns are read.

Group and Theme

In the next phase, we will organize what we have to determine where to focus our discussion because there is rarely time to discuss everything. I ask everyone or for large teams everyone who did not volunteer to read a column, to stand up and go to the board. At the board, we want everyone to do a silent sort (for speed). They should put like items near each other (without covering up the others). At this stage, it is ok for items to move across columns. Once they have a grouping, they should label the themes. It is ok to have a couple oddballs that don’t fit into the groups.

Prioritize

If you have 3 or less core themes, focus on those and start with the one with the most items. If you have more, then you need to prioritize. I like to use dot voting. I give each person 3 dots (Stickers) and ask them to vote on the topics they think are the most important to tackle. They can put all three on one item or spread them across multiple. They are voting for a theme not individual items. (Hint: ask them to place them on the Post-it as it is much more difficult to peel them off of the whiteboard or wall.)

Discuss

Based on the voting pick the top 3 items and set a timebox of about 15 minutes per item. Ask an open-ended question on the topic and then let the team own the discussion. (i.e. “So what do you guys see as the underlying problem here?”) As the facilitator, try and refrain from leading this discussion. We want the team to drive it and it is ok for the discussion to wander a bit. After 5-10 minutes, try and bring it to a close with something actionable the team can change. Prompt them into solutioning by asking something like, “So what can we as a team do about this?”

Take Action

Make sure the team comes up with actionable changes, i.e. SMART goals. Ensure the team discusses how they are going to make it happen. Create immediate tasks in the Sprint Planning session that should follow. Make the goals visible and part of the plan, i.e. put them on the task board.

Other Variations

Don’t let it get stale. Try different things. I recommend buying Esther Derby’s book (listed below) to help generate new ideas to keep your team engaged.
Other favorites: Speed Boat (Innovation Games), Triple Nickles (Esther), Mad/ Sad/ Glad (Esther)
Sometimes just have a conversation as a team
Occasionally just focus on a team-building exercise
The problems aren’t always clear and you will need to do some root cause analysis. Some great tools for that are a Fishbone and the Five Why’s.
It is ok for the ScrumMaster to set a focus topic of the retro. i.e. Let’s focus on self-organization or being releasable at the end of the sprint
For Release Retrospectives I like to do the Timeline (Esther) exercise or Remember the Future (Innovation Games)

References

Agile Retrospectives: Making Good Teams Great, Esther Derby & Diana Larsen
http://innovationgames.com/

Blog

Kanban vs. Scrum – How to Choose?

By: David Hawks | Feb 02, 2012 | Agile, Agile Tools, Article, Kanban, Scrum

Kanban vs. Scrum – Which is Right for my Team?

Clients frequently ask us when they should use Kanban and when they should use Scrum. To form a recommendation, these are some of the questions we ask:

What best describes the nature of your team’s work? Is it complex, risky, and/or new feature-oriented or is it well-defined, fluid, and/or more service-oriented?
If you answered yes to complex, risky, and/or new feature-oriented, score 1 for Scrum. If you answered yes to well-defined, fluid, and/or more service-oriented, score 1 for Kanban. The Scrum framework is designed to address complex, adaptive problems. Kanban is a Lean method applied to a team’s process in order to improve flow.

Do your priorities change often? Do you have trouble locking scope for 1-2 weeks at a time? Do you have more than 25% scope churn during a 2 week period?
If you answered yes to these questions, score 1 for Kanban. By dropping the fixed timebox, it may allow your team to adapt more easily to the quickly changing priorities of your business.

Do your teams struggle to break features into incremental pieces of value to be delivered in less than a week?
If you answered yes, score 1 for Scrum. Both approaches work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can help teams new to the practice recognize their deficiency (work not completed at the end of the sprint) and adapt (retrospective).

Can teams break work down to reasonably small, similarly sized chunks?
If yes to these, score 1 for Kanban. Kanban removes the overhead of estimation in favor of measuring cycle time for like-sized items.

Do your teams have a strong culture of continuous improvement and self-organization?
If so, score 1 for Kanban. The lightweight framework method that Kanban provides works very well in a culture of continuous improvement. They will determine the right times to hold a retrospective. For teams new to this practice, a regular cadence of a retrospective ceremony will help teams establish this practice.

Do your teams need to improve their discipline with technical practices and craftsmanship, such as TDD, Continuous Integration/Delivery, Shared Ownership, etc.?
If you answered yes, score 1 for Scrum. Both approaches excel in an environment of strong technical practices. Scrum can help teams iterate through improving their technical practices and delivery, by focusing on production worthy increments, as well as Sprint Reviews and Retrospectives.

Is your team’s top priority to optimize responsiveness to customer needs?
If so, score 1 for Kanban. Kanban has a strong focus on optimizing flow, while Scrum has a stronger focus on incremental delivery. Both can be tuned to provide similar outcomes, but Kanban offers the flexibility to lower batch size to reduce cycle time at the potential cost of productivity.

Is your team’s top priority to focus on predictability and productivity for larger projects?
If so, score 1 for Scrum. Again, you can achieve predictability and a high level of productivity with both approaches. For new teams, Scrum provides more guidance and resources for how to handle release planning and progress tracking.

What is the team’s appetite for process change?
If low, then score 1 for Kanban. Kanban is a method we apply to our existing process, whereas Scrum introduces a few events that may be new to the team. So, Kanban may be easier to introduce into your organization.

Does your organization / culture demand a higher degree of ceremony and artifact?
If so, score 1 for Scrum. Not that Scrum has a high level of ceremony, but it can integrate well into a culture requiring more structure and documentation. From a Lean perspective, we may question the need for these as potential waste. The reality is that sometimes we have to fit within a certain culture and incrementally work ourselves out of it.

Summary
Both Kanban and Scrum require strong discipline and rigor to be sustainably effective. Kanban doesn’t have as many rules, which is good, but it also can be ineffective with an undisciplined team. For example, undisciplined teams may constantly carry over unfinished work with Scrum or ignore WiP (work in progress) limits with Kanban. Scrum’s Sprint time box and Kanban’s WiP Limit both challenge teams to figure out how to break work down into smaller pieces to get them to a true state of ‘done’.

Teams most commonly successful with Kanban fit into two areas:

Support or Shared Services teams – These teams are focused on serving the organization to keep the production systems running or other critical business services. Their priorities can change on a daily basis. These teams need to be ultra-responsive. Kanban can enable these teams to optimize flow.
Mature, disciplined, self-organizing teams. They are engaged, have well-defined processes, understand how to break down work, and are constantly swarming to solve problems and get things done.

Choosing an approach that best suits your team’s needs can be greatly enhanced by providing formal training, supported by coaching.

Blog

Purpose Of The Daily Scrum Meeting

By: David Hawks | Jan 06, 2011 | Agile, Article, Scrum, ScrumMaster, Team

The Daily Scrum Meeting is for the TEAM to self-organize towards achieving their Sprint commitment.

Objectives

Team Sync – The daily scrum is for the team to review progress toward their Sprint goal
Assess Risks – The team assesses any risks to their Sprint commitment
Adjust Plan – The team makes adjustments to their plan to meet the sprint commitment
Full Team – It is important for all team members to attend
Team Goal – Everyone needs to approach the Sprint as a team goal, not a set of individual goals
Team Ownership – Each team member should own and share responsibility of the full sprint backlog
Accountability – The team should hold each other accountable for achieving their daily commitments

If you’re trying daily Scrums for the first time on your way to adopting Agile, we recommend our white paper, 8 Common Pitfalls to An Agile Transformation to prevent bumps on your Path to Agility®.

Myths

Myth	Correct Action
The meeting is a status meeting for management (or the ScrumMaster)	The ScrumMaster purely serves as a facilitator on behalf of the team. Status to folks outside the team can be a secondary benefit, but it is not the primary purpose.
You only have to attend the daily scrum if you accomplished something towards the Sprint goal	As a team member, it is still important for you to engage in what the rest of the team is doing. It is also important for the rest of the team to understand why you are struggling to make progress.
It is the ScrumMaster’s responsibility to monitor and adjust the plan	It is up to the team to own the plan and make any needed changes
Everyone provides status to the ScrumMaster	The team should provide status to each other
No one pays attention to each other’s status (focusing on individual goals)	The team should focus on the team goal
Only the ScrumMaster identifies risks and mitigations	The whole team has responsibility for identifying risks and developing mitigation strategies

Tools

Sprint Backlog – Allows the team to have visibility into all of the tasks remaining to achieve their sprint commitment
Sprint Burndown Chart – Allows the team to quantify the amount of work remaining and if the team is on track

Key Metrics

How many days are left in the Sprint? — This reinforces the urgency of a looming deadline
How many points have been signed off by the Product Owner? — This reinforces that it only matters if we complete stories (not just getting to code complete)
How many hours are remaining compared to our target plan? — This provides a view of how the team is progressing, most easily represented in a Sprint Burndown Chart.

If you’re trying daily Scrums for the first time on your way to adopting Agile, we recommend our white paper, 8 Common Pitfalls to An Agile Transformation to prevent bumps on your Path to Agility®.

Related Articles:

https://martinfowler.com/articles/itsNotJustStandingUp.html

Blog

Five Responsibilities of Team Members When Transitioning to Agile

By: David Hawks | Sep 27, 2010 | Agile, Article, Leadership, Team

Transitioning processes and cultures simultaneously is very difficult. A Successful Agile transition requires team ownership and engagement in developing the best process to fit your unique culture and environment. Five areas where team members are integral to push the process forward and become successful are outlined below.

Seek Constant Improvement

To achieve improvement, the team should define and align to the same goals. As a team, conduct an exercise to define the qualities of a successful team to focus them in the same direction and give them something to drive towards. Once the initial goals are met, set the bar higher, and always strive to be better. Celebrate success internally and market your success externally. Share what is working and what the team is learning with management and other teams.

Get Curious

It is important a team push themselves to be better. In this industry, it is no longer acceptable to just be a tech expert; you also need to work more productively in a team environment. Take advantage of numerous sources of information by reading books and blogs and sharing interesting tidbits with your peers. Learn how others work since someone else has probably encountered similar problems.

Challenge Everything

Just because someone else thinks it is the “right” way to do things, doesn’t mean it is. In early adoption, everyone is learning and no one is an expert. Always keep in mind there is no one right answer. Examine multiple points of view and try the approach the team thinks will succeed in your environment. It is natural to be skeptical, but try to be fair and open-minded.

Be Solution Oriented

It is imperative to maintain the right mental attitude. Change is stressful, but it is not constructive if you are not doing anything to fix it. Don’t just point out problems, but help devise solutions. Don’t blame outside the team, first determine how the team can solve the problem. If the struggle continues, then escalate.

Experiment

And the most important thing to keep in mind is in the beginning, you are not going to get it right. One advantage of short cycles is you can try something, gather some data, inspect the results, and adapt from there. Try different options and tweak a little bit at a time.

Blog

Why are our Sprints so Crazy?

By: David Hawks | Sep 03, 2010 | Agile, Article, Scrum, ScrumMaster, Team

If Your Sprints are crazy, do any of these issues sound familiar?

During Sprint Planning, it’s impossible for the team to break tasks into small enough chunks to be completed in a day
QA gets scrunched at the end of the Sprint
The team waits on design completion during the Sprint and cannot begin development tasks quick enough
Late in the process (sometimes after the Sprint ends), it’s determined that what was built wasn’t actually the right solution

Is there sufficient team prep work?

It’s a common misconception that within Scrum, the team should only work on the current Sprint’s stories and nothing more. However, this approach leads to inefficiency. In reality, every team should spend time preparing for the next Sprint in order to maximize productivity.

Requirements Clarity

To plan the story, the team needs to have a clear idea of what problem they are trying to solve and the boundaries on the scope. They need to work with the Product Owner, Stakeholders, Customers, and/or Users to better understand the focus of the upcoming stories. The team then works to refine the acceptance criteria to ensure it captures their understanding and assumptions of what is required by the story. This helps align expectations across all members of the team and with the folks requesting the story.
This can occur in full team discussions of the upcoming backlog with the Product Owner and Stakeholders, or with a couple members taking point to work through the details and then review with the team. Either way, all members of the team should possess a sufficient understanding of the business need.

Barely Sufficient Design

Once the clarity of the business intent is understood by the team, the focus turns to the solution. Some stories are small enough or don’t require substantial design making little impact if done during the Sprint, however others may require significant thought before unleashing the team for full planning or implementation. Typically, some activities (such as User Experience Design) occur before the beginning of the Sprint, so it’s available when tasking and the team isn’t blocked waiting on the UI Designer. This may also be required on a story that requires new Architecture decisions. If this activity is large enough, the team may need to break the story up so that it can be done incrementally. Perhaps do some prototyping work in one Sprint to prove out different technologies, followed by the final implementation story in a later Sprint. Or an incremental approach can be taken initially, avoiding the need to make a big up-front design decisions. (See Emergent Design).

Keep the goal in mind

The goal is to gain enough clarity of scope and solution to create a plan with sufficient accuracy relatively quickly, allowing the team to comfortably commit to a well detailed Sprint plan. The balance is to work ahead just enough without working too far ahead and without over-engineering prior to Sprint start.

How does this work in Practice?

Typically, a team should allocate 10% of their capacity to work ahead. This could be 10% of every team member or a more significant percentage for some folks (e.g. UX Designer, Architect). Every member of the team should be engaged in some capacity so it’s clear what the team is being asked to do as Sprint Planning begins.

The team should set up a forum with the Product Owner to review stories and acceptance criteria to flesh out details and find gaps. This could be a regularly scheduled meeting one week before the next Sprint. The Product Owner should provide the initial set of Acceptance Criteria, while the team also takes ownership to hammer out the rest of the details. If the responsibility stays solely on the Product Owner, the team may become blocked and won’t benefit.

For each story, the team should also determine if any pre-sprint design work needs to be done. If large enough, the team may need to create tasks for the current Sprint to have visibility into what needs to be done and who is doing it.

How does this solve our problems?

Better understanding of requirements and solution will allow the team to have enough knowledge to task out the work sufficiently
Since expectations are aligned between developers and QA up front, QA no longer has to wait until they get the code to figure out what they need to test
Serial design processes are done prior to the Sprint so that work can begin immediately after the planning session
Requirement details are worked out with stakeholders prior to development beginning

Blog

7 Principles of Lean Software Development

By: David Hawks | Apr 19, 2010 | Agile, Article, Lean

I recommend reading Implementing Lean Software Development by Tom and Mary Poppendieck. They do a good job of breaking down the 7 Principles of Lean Software Development into some very easy to understand concepts. Here is a taste of what this book will open your mind to:

Principle 1: Eliminate Waste

Waste is anything that interferes with giving customers what they really value at the time and place where it will provide the most value.
Inventory is waste – In software that is partially done work
Churn – Requirement Churn, Repeating test/fix cycles
Many times caused by large inventories of partially done work
When requirements are specified long before coding
When testing occurs long after coding
Delayed integration
Overproduction – Extra Features
Only about 20 percent of features in custom software are regularly used (66% are rarely used)

Principle 2: Build Quality In

You don’t focus on putting defects into a tracking system; you avoid creating defects in the first place.
Defect tracking systems are queues of partially done work
TDD and Continuous Integration
Write Less Code – Keep the Code Base Simple
Expect to change existing code
Refactor often

Principle 3: Create Knowledge

Software is a knowledge creating process
Validation of architecture comes as the code is being written
An early design cannot fully anticipate the complexity encountered during implementation
Expect the design to evolve
Early release of minimum feature set to customers for evaluation and feedback
Daily builds and rapid feedback from integration tests
A modular architecture that supports the ability to easily add new features
Encourage systematic learning throughout the development cycle
Stop acting as if our predictions of the future are fact rather than forecast. Instead, we need to reduce our response time so we can respond correctly to events as they unfold

If you want to begin implementing Lean and Agile principles, learn about your adoption options with our infographic, Implementing Agile.

Principle 4: Defer Commitment

Schedule irreversible decisions for the last responsible moment
We should try to make most decisions reversible
We should avoid making decisions that will lock in a critical design decision that will be difficult to change
“In preparing for battles I have always found that plans are useless, but planning is indispensable” Dwight Eisenhower

Principle 5: Deliver Fast

We need to figure out how to deliver software so fast that our customers don’t have time to change their minds
Companies that compete on the basis of time often have a significant cost advantage
Eliminated a huge amount of waste
Low defect rates
Repeatable and reliable speed is impossible without superb quality
In fast-moving organizations, the work is structured so that the people doing the work know what to do without being told and are expected to solve problems and adapt to changes without permission

Principle 6: Respect People

Entrepreneurial Leader
A company that respects its people develops good leaders and makes sure that teams have the kind of leadership that fosters engaged, thinking people focused on creating a great product
Expert Technical Workforce
Appropriate technical expertise is nurtured
Teams are staffed with needed expertise to accomplish their goals
Responsibility-Based Planning and Control
Teams are given general plans and reasonable goals and are trusted to self-organize to meet the goals

Principle 7: Optimize the Whole

A lean organization optimizes the whole value stream
Vicious Circle #1
A customer wants some new features, “yesterday.”
Developers hear: Get it done fast, at all costs!
Result: Sloppy changes are made to the code base.
Result: Complexity of the code base increase
Result: Number of defects in the code base increases
Result: There is an exponential increase in time to add features
Vicious Circle #2
Testing is overloaded with work
Result: Testing occurs long after coding
Result: Developers don’t get immediate feedback
Result: Developers create more defects
Result: Testing has more work. Systems have more defects
Result: Feedback to developers is delayed further. Repeat cycle.

If you are looking for a basic introduction to Lean Concepts I would recommend reading the Goal.

If you want to begin implementing Lean and Agile principles, learn about your adoption options with our infographic, Implementing Agile.

What’s Your Organizational Agility Score?

In less than an hour, you’ll get valuable insights into your organization so you can improve team performance and achieve your business goals faster.

Blog

4 Advantages of Physical Task Boards

By: David Hawks | Mar 07, 2010 | Agile, Article, Scrum, ScrumMaster

For new teams, I try and encourage them to use a physical task board over tracking tasks in a tool. This can be problematic when all team members are not in the same location, but it has some huge advantages for co-located teams.

Structure of our Task Board:

5 Columns: Planned, In Progress, Verify, Hours Remaining, Complete
Each Committed story for the iteration is given a swimlane/ row
All Development tasks are on white cards
All Testing tasks are on green cards
All defects are on hot pink cards
Orange sticker dots were used for tasks that are blocked
Story cards are 4×6, task cards are 3×5
We have used whiteboards with tape or cork board with push pins
Daily Standups are done in front of the board, we encourage team members to point at the card during their 3 questions, move cards, burndown hours. Each team member should be signing up for their daily commitment and putting those cards in progress.
Hours burndown is updated for each story at end of standup
Burndown chart and any other metrics are placed on and around the board – radiate information
Should be visible to all team members (i.e. that way when a QA person sees a developer move a task they know to ask if it is ready for testing)

Advantages of Task Boards:

Promotes team interaction and discussion – Throughout the day you will see teammates, stakeholders and members of other teams stop by the board for discussion. This increases greatly if the board is located near the team and highly visible
Visibility – Anyone walking buy can make a quick second assessment on where the team is in the iteration. No cards left for a row? That story is complete. No white cards left, just green cards? Only testing remains. Lots of pink cards? Lots of defects.
Good for new teams to visualize Scrum – By having this tangible thing in front of them that they can touch, makes it easier for new Scrum teams to understand the process
Support full team commitment – Now the whole team sees all of the tasks daily and keeps them from just focusing on “their” tasks. When using task tracking tools it is too easy to just create a view of “my tasks” and then tune out the rest.

Blog

5 Reasons Why Estimating in Story Points is a Superior Method

By: David Hawks | Feb 21, 2010 | Agile, Article, ScrumMaster, Team

I get a little resistance from teams to start using Story Points for estimating, but it really is a superior way to estimate over hour based estimates.

Story Points should be used to estimate User Stories and quickly provide estimates to the Product Owner so that they can prioritize the product backlog. I recommend using the Planning Poker technique to get everyone on the team involved and timebox the estimating process.

What are Story Points?

Story Points are a relative measure of complexity, i.e. How big a feature is compared to other features. This type of estimating removes the notion of time from the estimate as team productivity is measured separately as Velocity.

Advantages:

Quicker to Estimate
- Keeps Things Relative – Two team members can agree quicker that one feature is twice as complex as another compared to agreeing on how long it will take to implement. A senior developer may argue that it takes 2 days while it will take 4 days for a junior developer.
- Stay out of the Weeds – If the team has to think about every little thing to build a bottoms-up hours estimate then they will tend to try and understand every requirement detail and think through the design too much. When estimating in points you only have to think about comparative complexity, as opposed to trying to think about everything required to implement the feature.
Do Not Get Stale – As team productivity changes there is no need to re-estimate. Velocity will change but the comparative complexity will still be valid.
Better Metrics – Since the scope is isolated from productivity I can now report on how the scope is changing. If I had my estimate in hours it is difficult to determine if the change was from a scope or productivity change. For a release I like to report two main things to my stakeholders: scope (total points recorded at each sprint) and work completed/ velocity. This gives me clear visibility to both scope and velocity compared to the plan.
Inaccurate Estimates get Resolved – If up front the team made overly optimistic or pessimistic estimates we will gain quick visibility to this as the team records Velocity in the first couple iterations.We will then be able to adjust the plan accordingly without having to re-estimate.

This post will tell you how to get started.

Articles of Reference:
The Case for Story Points – Peteon Rails
How Do Story Points Relate to Hours? – Mike Cohn
Agile Estimating Presentation – Mike Cohn

Blog

5 Effects of Shippable Product Every 30 Days

By: David Hawks | Feb 07, 2010 | Agile, Article, Product Owner, Scrum, Team

“What do you think the impact will be on an organization of having a potentially shippable product increment at least every 30 days?”

This is one of the hardest feats to accomplish, but a critical component in highly successful Scrum.

Here are my top 5 advantages of a Shippable Product Every Month:

Customer/ stakeholder engagement -By demonstrating that the team can be responsive to their needs you will find that your stakeholders will become more engaged because the process becomes more rewarding for them. If you do not deliver something for 6 months they will lose interest.
Team satisfaction/ accomplishment – The team morale will increase and this will increase productivity as the team gets validation that they are delivering value to the organization on a frequent basis.
Predictability – If all tasks are fully completed on a monthly basis this allows for better predictability as everything is complete compared to a process where there are x number of cleanup tasks to be done some months later. Or x number of defects remain open with an inaccurate estimate of when they will be completed.
Remove the notion of the development team as a bottleneck – In many organizations the software development team is viewed as the bottleneck. After requirements are defined the project sits in development for months. By increasing the “flow” through development they will move the bottleneck to somewhere else in the organization. Then attention can focus on improving the efficiency in that department.
Quicker ROI – If you can deliver 1/6th the project in the first month and get it in production you are accelerating the return on investment and shortening the payback period.

Blog

The value of developers doing Acceptance TDD

By: David Hawks | Jan 21, 2010 | Agile, Agile Technical Practices, Article

I believe Test-Driven Development is one of the key Agile practices that should be combined with Scrum in order to be highly productive. Scott Ambler’s recent article on Tragic Mistakes When Adopting Test-Driven Development (TDD) in Dr. Dobbs.outlines TDD.

Two forms of TDD

With “developer TDD”you typically use a xUnit tool, such as JUnit for Java or VBUnit for Visual Basic, to write developer tests. Developer tests, which include unit tests and simple integration tests, specify and validate the design of your code.
With “acceptance TDD” you use more sophisticated tools, such as the Fitnesse framework, to write what’s often referred to as agile acceptance tests or story tests. These tests specify and validate your code.

I hear many people talking about TDD in the context of unit testing but very few including the acceptance level. I believe this is a very crucial piece in order to be highly productive. This involves a shared ownership amongst the team across developers and QA. However, if you successfully get the developers engaged in writing their code to make an acceptance test pass, which is aligned with the acceptance criteria in a User Story, you can ensure they are writing barely sufficient code and increase productivity greatly. Productivity can be increased in the following ways:

With a less rigid structure to the roles there is less handoff between developer and QA. QA’s function here would be to review the tests to ensure they satisfy the acceptance criteria and that all of the proper scenarios have been tested. This also makes it easier to get fully tested and releasable code by the end of the iteration. Without this QA typically is waiting until the code is written before they can test adding lag to the process.
Defects will be found sooner and by the developer writing the code. If the tests are run in the same cycle as the code be written (preferably prior to check in), this allows for higher quality and less waste in the process.

“What is the role of QA if they aren’t doing the acceptance tests?”

QA can then focus their energies on:

Assurance – reviewing the tests that the developers are writing to ensure quality and completeness
Analysis – work with the Product Owner to ensure the completeness of the requirements/ acceptance tests. Developers typically get focused on a single portion of the system, QA needs to focus on understanding the big picture and business intent.
Integration – automation of integration level tests across the project
Manual testing/ Edge Case – not all tests are worth automating (time to write, time to execute) and the QA strategy should be defined by the team for each story. These tests may still be documented and executed infrequently
Ad hoc/ exploratory – With the big picture understanding they can still spend some small amount of time “using” the system as a user would

I have seen teams continue to increase the QA to Dev ratio almost up to 1:1 in order to achieve releasable and testable product by the end of the iteration. Is this really the most efficient and flexible use of resources? If developers were more engaged in “Acceptance TDD” would you need this?