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

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

A swiss army knife - tools of the daily scrum

  • 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

Sprints - Runners SprintingIf 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 mindTarget - Keep a Goal in Mind in your Sprint

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.

 

 

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.

Learn more

Blog

4 Advantages of Physical Task Boards

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

Example Task BoardFor 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

Relative sizing of peanut butter cups - story points sizing for estimationI 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

Container ship with a shippable product“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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

Math Test -- Acceptance TDDI 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?

 

 

Blog

Struggle with Self Organizing teams

By: David Hawks | Jan 13, 2010 |  Agile,  Article,  Team

Self-organizing teams - organizational chartI think getting teams to be self-organizing in a productive way is one of the toughest challenges of Scrum.

I remember early on in our adoption of Scrum when I was having trouble getting the teams to embrace a self-organizing culture. I brought in a trainer/coach and after careful observation, he told the management team the following:

“It is great that you guys are so curious and energetic about helping the teams, but you have to stop and get out of the way. You need to stop solving the problems for the team and let them start solving the problems themselves. Also, you need to find a way to motivate them to become curious about the process and for them to be energetic about figuring out how to be better.”

This was a huge moment for me in my progression on learning how to be a better Agile practitioner.

I think most good leaders got to where they are today because they are great problem solvers. Unfortunately, this gets in the way when are trying to encourage a Scrum team to become self-organizing. If we jump in and solve the problems, the natural tendency for the team is to let us do it (especially if we are their managers). This is the part where you have to give the team some rope and let them struggle through some of their own mistakes. This is painful to watch when you are probably confident you know a solution. You must find a way to facilitate the team through the problem without solving it for them.

Further Reading:
The Role of Leaders on a Self-Organizing Team | Mike Cohn’s
Blog – Succeeding With Agile�

Blog

What can we learn from the failure of Duke Nukem?

By: David Hawks | |  Agile,  Article

Duke NukemI just read an article about how the Duke Nukem project went on for 12 years and never released.

A comment from the article, “he did not appear to have an endgame — an overall plan for what the finished product would look like, and thus a way to recognize when it was nearing completion”

This is a common problem I see with Agile. Not having a release goal and plan. The risk of just working off of a backlog in priority order from iteration to iteration is, “when are you finished?” Some Agile advocates would say, “whenever you want to be,” however if you have a Product Owner, like Broussard in this article, who keeps wanting more and more then you may never release. Setting a goal and having a plan will help you be more disciplined and stick to it.

Full article:
Learn to Let Go: How Success Killed Duke Nukem | Magazine:

Related Posts:

Getting to Done