Posts Tagged ‘agile’

Guidance on Running Retrospectives

July 28, 2012

Following is the five steps we use to run our Retrospectives.
I’ve purposely made these as terse as possible,
so it can be used as a check list as the retrospective progresses.
Below the five steps I’ve added some extra info and tips.

What’s a Retrospective?

  • A Retrospective is a planned event where a team leader
    (or in the world of Scrum, a Scrum Master)
    guides the team through a process of looking inward.
    In the world of Scrum, we hold a Retrospective at the end of every Sprint.
    What’s Scrum?
    I made a post a while back outlining why an organisation aiming to deliver products that had complex elements, would use Scrum.
    Check it out here.
  • Locating impediments and working out what to do in order to remove them.
  • Move the team along the path of…
    Forming -> Storming -> Norming -> Performing.
  • Make the team a more fun place to be for all members.
  • Implement Kaizen.
  • Increases operational efficiencies for the stake holders.
  • Another opportunity to inspect and adapt.

Structure

  1. Set the stage
  2. Gather data
  3. Generate insights
  4. Decide what to do
  5. Close the retrospective

1. Set the stage

Time expected (time box)
  • Ask everyone in room to speak a word or two about what’s going on / how they’re feeling.
    This encourages everyone to have a voice and speak early.
    If anyone chooses to remain silent, they must remain silent for duration of Retrospective.
  • Request for amendments to our working agreements?
    These belong to the team.
    They are the teams responsibility.
    Social contract (> 10 points is too many).
    Check whether the Definition of Done (DoD) needs any modifications.
  • Establish environment where people can bring up difficult topics and have challenging conversations.
    Confirm (and establish if not already) the goal of this Retrospective.
    Remind team that Social contract applies for retrospective as it does at any other time.
    Teams personal Social contract should not contain abstract statements,
    but working statements and agreements that help the team talk about emotional, tough issues.
  • If someone is doing to much talking, just say “Lets hear from someone else”.
    Some Product Owners can have this tendency.
  • Review Action Points taken from last Retrospective.

2. Gather data

Time expected (time box)
  • Hard
  • events
  • metrics
  • features or PBI’s completed
  • Soft
  • feelings
    Rather than asking directly about how people felt, you can get the same info in other ways.
    When were you excited to come to work?
    When was coming to work “just a job”?
    When did you dread coming to work?
    What were the high points?
    What were the low points?
    How was it to be in this iteration?
    When where you mad, sad, surprised?

3. Generate insights

Time expected (time box)
  • Question why, and encourage team to start thinking about what to do differently.
  • Lead team to examine the conditions, interactions, surprises and patterns that contributed to the Sprint outcome.
  • Record all insights on the white board or a wall.
    insights are potential experiments and improvements taken from the gathered data.

4. Decide what to do

Time expected (time box)
  • Team picks the top 2 – 3 insights.
    These become the action points.
    Make sure each action point is assigned to someone and dated.
    The best way to make sure these happen is to include them in the next Sprints Backlog as PBI’s.

5. Close the Retrospective

Time expected (time box)
  • Make mention of the Sprint report and that all should read through it at least once to keep the decisions made in their mind.
  • The learning’s belong to the team. Not the CEO and Not the SM.
  • Show appreciation for the hard work everyone did during the Sprint and the Retrospective.
  • Perform Retrospective on Retrospective (a few minutes).
    It pays to inspect and adapt Retrospectives too.
    Or as the military call it, OODA loop.
    Observe -> Orient -> Decide -> Act

That’s basically it.

Additional Retrospective info and tips

The Retrospective is generally the last event in a Scrum Sprint.
The official Scrum Guide has a terse section on the Retrospective.

Time boxing

Scrum values time box’s.
Generally time boxed to 1.5 hours for a 2 week Sprint.
Proportionally shorter / longer for shorter / longer Sprints.
A general guideline for the 5 steps are:

  1. Set the stage 5%
  2. Gather data 30-50%
  3. Generate insights 20-30%
  4. Decide what to do 15-20%
  5. Close the retrospective 10%

Activities

I’m finding it useful building up a collection of activities to use to drive the Retrospectives.
Have an activity pre-defined for each of the five steps, and potentially a fall back activity also.
It pays to spend some time up front before the event,
preparing what you want the stake holders and the Team to get out of it (a goal).
Good activities to use, should include at least the following traits:

  1. Encourage all team members to actively participate.
  2. Help team members to keep discussions focused on the goal.
  3. Assist in producing creative thinking, and looking at things from different angles.

Don’t use the same activities every Retrospective.
If you and / or the Team is getting bored with the current activity, it’ll become less effective.

Breaks

If your running a Retrospective longer than aprx 2 hours,
you should think about factoring in breaks.
Often 10 minutes is all the team will need.
You as the Retrospective leader / Scrum Master, will benefit from a short break.
Especially if your feeling stressed or under tension.
Shake the tension out of your limbs and get the blood moving to the brain again.
Take a few good breaths.

Closing

I’ve found the book “Agile Retrospectives” by Esther Derby very useful.
Check it out for lots of additional info and ideas.

I wanted to keep the five steps really terse (a check list).
This way you can take them into the Retrospective and glance at them while your leading the event to make sure you and the team are on track.

Comments very welcome.

Advertisements

How to optimise your testing effort

March 24, 2012

I recently wrote a post for the company I currently work for around the joys of doing TDD.
You can check it out here.

What is your current approach to testing?
How can you spend the little time you have on the most important areas?

I thought I’d share some thoughts around where I see the optimal areas to invest your test effort.
I got to thinking last night, and when I was asleep.
We are putting too much effort into our UI, UA and system tests.
We are writing to many of them, thus we’re creating a top heavy test structure that will sooner or later topple.
These tests have their sweet spot, but they are slow, fragile and time consuming to write.

We should have a small handful for each user story to provide some UA, and the rest should be without the UI and database (the slow and fragile bits).
We need to get our mind sets lower down the test triangle.

test triangle

I’ll try and explain why we should be doing less Manual tests, followed by GUI tests, followed by UA tests, followed by integration tests, followed by Unit tests.

Try not to test the UI with the lower architectural layers included in the tests.
UI tests should have the lower layers mocked and / or stubbed.
Check out Dummy vs Fake vs Stub vs Mock
Full end to end system tests are not required to validate UI field constraints.
Dependency injection really helps us here.

When you are explicitly testing the upper levels of the test triangle, the lower / immediate lower layers are implicitly being tested.
So you might think, cool, if we invest in the upper layers, we implicitly cover the lower layers.
That’s right, but the disadvantages of the higher level tests outweigh the advantages.
UI tests and especially ones that go from end to end, should be avoided, or very few in number,
as they are fragile and incur high maintenance costs.
If we create to many of these, confidence in their value diminishes.
Read on and you’ll find out why.

Lets look at cost vs value to the business.

Some tests cost a lot to create and modify.
Some cost little to create and modify.
Some yield high value.
Some yield low value.
We only have so much time for testing,
so lets use it in the areas that provide the greatest value to the business.
Greatest value of course, will be measured differently for each feature.
There is no stock standard answer here, only guidelines.
What we’re aiming for is to spend the minimum effort (cost) and get the maximum benefit (value).
Not the other way around…
With the following set of scales, we’ve spent to much in the wrong areas, yielding suboptimal value.

cost verse business value

It’s worth the effort to get under the UI layer and do the required setup incl mocking the layers below.
It’s also not to hard to get around the likes of the HttpContext hierarchy of classes (HttpRequest, HttpResponse, and so on) encountered in ASP.NET Web Forms and MVC.

Beware

  • the higher level tests get progressively more expensive to create and maintain.
  • They are slower to run, which means they don’t run as part of CI, but maybe the nightly build.
    Which means there is more latency in the development cycle.
    Developers are less likely to run them manually.
  • When  they break, it takes longer to locate the fault, as you have all the layers below to go through.

Unreliable tests are a major cause for teams ignoring or losing confidence in automated tests.
UI, Acceptance, followed by integration tests are usually the culprits for causing this.
Once confidence is lost, the value initially invested in the automated tests is significantly reduced.
Fixing failing tests and resolving issues associated with brittle tests should be a priority to remove false positives.

Planning the test effort

This is usually the first step we do when starting work on a user story,
or any new feature.
We usually create a set of Test Conditions (Given/When/Then)

Given When Then
There are no items in the shopping cart Customer clicks “Purchase” button for a book which is in stock 1 x book is added to shopping cart. Book is held – preventing selling it twice.
Customer clicks “Purchase” button for a book which is not in stock Dialog with “Out of stock” message is displayed and offering customer option of putting book on back order.

for Product Backlog items where there are enough use cases for it to be worth doing.
Where we don’t create Test Conditions, we have a Test Condition workshop.
In the workshop we look at the What, How, Who and Why in that order.
The test quadrant (pictured below) assists us in this.
In the workshop, we write the previously recorded Acceptance Criteria on a board (the What) and discuss the most effective way to verify that the conditions are meet (the How)
With the how we look at the test triangle and the test quadrant and decide where our time is most effectively spent.

Test condition workshop

With the test condition workshop,
when we start on a user story (generally a feature in the sprint backlog),
we plan where we are going to spend our test resource.
Think about What, and sometimes Who, but not How.
The How comes last.

Unit tests are the developers bread and butter.
They are cheap to create and modify,
and consistently yield not only good value to the developers,
but implicitly good value to most / all other areas.
This is why they sit at the bottom of the test triangle.
This is why TDD is as strong as it is today.
test quadrant

The hierarchy of criteria that we use to help us

  1. Release Criteria
    Ultimately controlled by the Product Owner or release manager.
  2. Acceptance Criteria
    Also owned by the Product Owner.
    Attached to each user story, or more correctly… product backlog item.
    The Development team must meet these in order to fulfill the Definition of Done.
  3. Test Conditions
    When executable, confirm the development team have satisfied the requirements of the product backlog item.

Write your tests first

TDD is  not about testing, it’s about creating better designs.
This forces us to design better software. “Testable”, “Modular”, separating concerns, Single responsibility principle.
This forces us down the path of SOLID Principles.

red green refactor

  1. Write a unit test
    Run it and watch it fail (because the production code is not yet written)
  2. Write just enough production code to make the test pass
  3. Re-run the test and watch it pass

This podcast around TDD has lots of good info.

Continuous Integration

Realise the importance of setting up CI and nightly builds.
The benefit of having your unit (fast running) tests automatically executed regularly are great.
You get rapid feedback, which is crucial to an agile team completing features on time.
Tests that are not being run regularly have the risk that they may be failing.
The sooner you find a failing test, the easier it is to fix the code.
The longer it’s left unattended, the more technical debt you accrue and the more effort is required to hunt down the fault.
Make the effort to get your tests running on each commit or push.

Nightly Builds

The slower running tests (that’s all the automated tests above unit tests on the triangle), need to be run as part of a nightly build.
We can’t have these running as part of the CI because they are just too slow.
If something gets in the way of a developers work flow, it won’t get done.

Pair Review

Don’t forget to pair review all code written.
In my current position we’ve been requesting reviews verbally and responding with emails, comments on paper.
This is not ideal and we’re currently evaluating review software, of which there are many offerings.

Professional Scrum Master

March 23, 2012

Hi all.

Looking forward to attending the PSM course on Monday 26/03.
Shortly after I’ll be going for the exam.

I’ve been mostly working in a scrum environment since around 2007.
Now I’m looking at solidifying some of that experience and knowledge, and gaining a little more hopefully?

Here’s the outline.

Scrum.org has designed the Professional Scrum Master (PSM) program to have the utmost rigor. The program’s courses, assessments, and certifications give participants the knowledge they need to use Scrum effectively and the credentials they need to communicate this ability in the marketplace.

Audience

The audience of the PSM course includes those that help lead the software development process in an organization. PSM is specifically targeted at the role of the Scrum Master, but the lessons are applicable to anyone in a role that supports a software development team’s efficiency, effectiveness, and continual improvement.

The Course

The Professional Scrum Master course is the first significant update of the Certified ScrumMaster (CSM) course that Ken Schwaber first created in 2002. This course covers Scrum basics, including the framework, mechanics, and roles of Scrum. But it also teaches how to use Scrum to optimize value, productivity, and the total cost of ownership of software products. Students learn through instruction and team-based exercises, and they are challenged to think on their feet to better understand what to do when they return to their workplaces.

Scrum.org maintains a defined curriculum for the Professional Scrum Master courses and selects only the most qualified instructors to deliver them. Each instructor brings his or her individual experiences and areas of expertise to bear, but all students learn the same core course content. This improves their ability to pass the Professional Scrum Master assessments and apply Scrum in their workplaces.

The Professional Scrum Master course (previously known as the Scrum In Depth course) covers Scrum basics, including the framework, mechanics, and roles of Scrum. But it also teaches how to use Scrum how to optimize value, productivity, and the total cost of ownership of software products. Students learn through instruction and team-based exercises, and they are challenged to think on their feet to better understand what to do when they return to their workplaces.

The course curriculum covers:

  • Scrum Basics. What is Scrum and how has it evolved?
  • Scrum Theory. Why does Scrum work and what are its core principles? How are the Scrum principles different from those of more traditional software development approaches, and what is the impact?
  • Scrum Framework and Meetings. How Scrum theory is implemented using time-boxes, roles, rules, and artifacts. How can these be used most effectively and how can they fall apart?
  • Scrum and Change. Scrum is different: what does this mean to my project and my organization? How do I best adopt Scrum given the change that is expected?
  • Scrum and Total Cost of Ownership. A system isn’t just developed, it is also sustained, maintained and enhanced. How is the Total Cost of Ownership (TCO) of our systems or products measured and optimized?
  • Scrum Teams. Scrum Teams are self-organizing and cross-functional; this is different from traditional development groups. How do we start with Scrum teams and how do we ensure their success?
  • Scrum Planning. Plan a project and estimate its cost and completion date.
  • Predictability, Risk Management, and Reporting. Scrum is empirical. How can predictions be made, risk be controlled, and progress be tracked using Scrum.
  • Scaling Scrum. Scrum works great with one team. It also works better than anything else for projects or product releases that involve hundreds or thousands of globally dispersed team members. How is scaling best accomplished using Scrum?

Prerequisites

The Professional Scrum Master course is primarily targeted at those responsible for the successful use and/or rollout of Scrum in a project or enterprise. Attendees will be able to make the most of the class if they:

  • Have attended the Professional Scrum Foundations course
  • Understand the basics of project management.
  • Understand requirements and requirements decomposition.
  • Have been on or closely involved with a project that builds or enhances a product.
  • Have studied the Scrum Guide.
  • Have read one of the Scrum books.
  • Want to know more about how Scrum works, how to use it, and how to implement it in an organization.

Assessment and Certification

As a matter of principle, Scrum.org feels that certification should be available to all those who possess a particular level of knowledge — not only to those who have taken a class. As a result, they offer the option of Professional Scrum Master I and II assessments to the public — not only to those who have taken the Professional Scrum Master course. The Professional Scrum Master program features two assessments and two levels of certification.