Skip to content

Feed aggregator

Neo4j: Cypher – Creating relationships between a collection of nodes / Invalid input ‘[‘:

Mark Needham - Sat, 04/19/2014 - 08:33

When working with graphs we’ll frequently find ourselves wanting to create relationships between collections of nodes.

A common example of this would be creating a linked list of days so that we can quickly traverse across a time tree. Let’s say we start with just 3 days:

MERGE (day1:Day {day:1 })
MERGE (day2:Day {day:2 })
MERGE (day3:Day {day:3 })
RETURN day1, day2, day3

And we want to create a ‘NEXT’ relationship between adjacent days:


The most obvious way to do this would be to collect the days into an ordered collection and iterate over them using FOREACH, creating a relationship between adjacent nodes:

MATCH (day:Day)
WITH day
FOREACH(i in RANGE(0, length(days)-2) | 
  CREATE UNIQUE (days[i])-[:NEXT]->(days[i+1]))

Unfortunately this isn’t valid syntax:

Invalid input '[': expected an identifier character, node labels, a property map, whitespace, ')' or a relationship pattern (line 6, column 32)
"            CREATE UNIQUE (days[i])-[:NEXT]->(days[i+1]))"

It doesn’t seem to like us using array indices where we specify the node identifier.

However, we can work around that by putting days[i] and days[i+1] into single item arrays and using nested FOREACH loops on those, something Michael Hunger showed me last year and I forgot all about!

MATCH (day:Day)
WITH day
FOREACH(i in RANGE(0, length(days)-2) | 
  FOREACH(day1 in [days[i]] | 
    FOREACH(day2 in [days[i+1]] | 
      CREATE UNIQUE (day1)-[:NEXT]->(day2))))

Now if we do a query to get back all the days we’ll see they’re connected:

2014 04 19 07 32 37
Categories: Blogs

The Agile Checklist Manifesto

Agile Management Blog - VersionOne - Fri, 04/18/2014 - 18:09


Airline pilots use a checklist to clear their planes for takeoff.  In an experiment Dr. Pronovost, a critical care specialist at John Hopkins, used the checklist strategy to attack just one common problem in the I.C.U., infections in patients with central intravenous lines. Dr. Atul Gawande is the author of The Checklist Manifesto: How to Get Things Right. He is a MacArthur Fellow, a general surgeon at the Brigham and Women’s Hospital in Boston, a staff writer for The New Yorker, and an assistant professor at Harvard Medical School and the Harvard School of Public Health. In his review of The Checklist Manifesto book, famous writer Malcolm Gladwell states “Although the book is written by a surgeon …. it is really relevant to how professionals deal with the increasing complexity of their responsibilities…It has been years since I read a book so powerful and so thought-provoking.”  No wonder, the book is a New York Times, Wall Street Journal, USA Today, Entertainment Weekly, Washington Post, Los Angeles Times, Boston Globe, and San Francisco Chronicle Bestseller. The important point Dr. Gawande is making is that the complexities of professional work in the 21st century may be best handled by the simplest solution of checklists. The counterpoint usually comes in two flavors: ·         My job is too complicated (or too important) to reduce to checklists – an argument by cynical surgeons that Dr. Gawande ran into.  This argument is easily refuted with the success Dr. Gawande’s checklists have enjoyed in hospitals. ·         Checklists reduce my flexibility, creativity, spontaneity; or they are too bureaucratic.  The argument can be refuted by recognizing that any tool can be misused.  Rigidly enforced, top-down, heavy-handed, compliance-oriented, slavishly-followed checklists will indeed create problems; but highly customizable checklists developed by professionals and teams of professionals doing the work, supported by appropriate tool, and used by those empowered professionals can be very helpful.  These kinds of smart checklists will take the drudgery and errors out of complex work, and thus, freeing up time for creative work. As incisively reported by Robin Marantz Henig in her New York Times article, checklists work really well because ”In an age of unremitting technological complexity, where the most basic steps are too easy to overlook and where overlooking even one step can have irremediable consequences, something as primitive as writing down a to-do list to “get the stupid stuff right” can make a profound difference.” I have been using checklists in my own agile coaching, training, consulting engagements: travel checklist, logistics checklist, preparatory homework checklist, follow-up checklist, etc.   Overlooking one critical step has proved damaging and harmful (at least to me and sometimes to my clients), and my checklists have been the saviors.  They unburden me and my clients from having to remember stuff or not miss the obvious in the frenzy of many things swirling around us.  Life becomes more relaxed, and error rate and goof-ups go down dramatically. Most of us working in agile development or agile management are neither airline pilots nor surgeons, but we deal with complex projects involving many people and teams, and lots of rapidly changing details where the devil lurks.  Simple, customizable checklists, in my experience, are highly effective in slaying the complexity devil. I will now present several examples of checklists applicable at the level of individual agile team members as well as agile teams.  Each checklist contains a number of items (such as tasks, tests, steps, options, questions) with a role assigned to each item (task, test, and step).  A checklist may or may not imply any order for items in it, or it may include a built-in workflow.    I recommend you review, customize and try the checklists presented in this blog, and then relentlessly inspect and adapt them, i.e., make them work for you with fine tuning and revisions based on your own experience.   If a task in a checklist is not applicable in your specific situation, you are free not to do that task with a reason that you can explain to yourself and to your team members.   If a specific task quite often need not be done or is missing in a checklist, the checklist itself should be revised (inspect and adapt) by deleting the unneeded or adding the missing task in the checklist.  You will be a lot more effective that way instead of  trying to recall from your memory without any checklist all the tasks you may have to do (and then missing at least some, or a lot, or them).

User Story Checklist

Table 1 shows a checklist of typical tasks and tests in a user story.  This should help a cross-functional agile team to pay attention to all these tasks and tests and not miss any work for the story in order to complete it and get it accepted by the product owner.   If a story requires multiple design and code development tasks and multiple acceptance tests, more tasks and tests can be added to that specific story than shown in Table 1.  Some tasks in Table 1 are optional, and may not be needed for a specific story.

Table 1: Tasks and tests in User Story Checklist

Table1 Defect Checklist

Defects found, especially outside a sprint such as in production, can be logged with the following checklist of tasks and tests.

  1. Task: Log the defect with steps to reproduce the defect: QA tester
  2. Task: Analyze and debug the defect: Developer
  3. Task: Fix the defect: Developer
  4. Task: Specify the test to verify the defect: QA tester
  5. Test: Execute the test to verify it: QA tester
  6. Task: Close the defect which has been verified as fixed: QA tester

Epic Breakdown Checklist

This checklist is based on the work done by Richard Lawrence where he recommends 9 patterns that you should try to use to break down an epic (a large story or feature) into smaller user stories.  I have listed these 9 patterns as options below. A customized checklist augmented with a brief example for each pattern suitable for your organization will be very handy and effective when it comes to breaking down epics into stories.

  • Option 1: Workflow Steps
  • Option 2: Business Rule Variations
  • Option 3: Major Effort
  • Option 4: Simple/Complex
  • Option 5: Variations in Data
  • Option 6: Data Entry Methods
  • Option 7: Defer Performance
  • Option 8: Operations (e.g., CRUD)
  • Option 9: Break Out a Spike

Sprint Planning Readiness Checklist

This checklist consists of a list of preparatory tasks that should be completed before starting a Sprint Planning Workshop or Meeting.  These tasks should be completed ideally one timebox ahead, i.e., in parallel with the previous sprint execution.  Completion of these preparatory tasks will help ensure a highly effective and productive sprint planning workshop, which is a time-boxed event (1/2 day for a two-week sprint or one day for a four-week sprint).

  1. Task: Define the Agile team, its members and their roles/responsibilities: ScrumMaster
  2. Task: Draft the key objectives for the upcoming Sprint: Product Owner
  3. Task: Define and create the project hierarchy in Agile Project management (APM) tool, and make sure the members of the Agile team have the right role assigned on the project:  ScrumMaster working with APM tool administrator
  4. Task: Create the Sprint backlog in APM tool: Product Owner working with Business analysts: Epics, stories (preferably satisfying the INVEST criteria, Defects, Spikes, Maintenance work, porting work, certification work, Regression testing, System testing, Performance testing, etc.
  5. Task: Explain and clarify the sprint backlog to team members for the upcoming sprint by conducting one or more sessions one timebox ahead, i.e., sprint work done in a pipeline mode (see details in my blog on Is Your Sprint Pipeline Running Well?): Product Owner.
  6. Task:  Calculate agile capacity for the team and each team member for the upcoming sprint (for capacity-based sprint planning – see details in my blog on agile capacity calculation): ScrumMaster working with each team member
  7. Task: Prepare the preliminary rank order of backlog items based on business value (Optional): Product Owner
  8. Task: Make sure all IT environments are in place: ScrumMaster working with IT staff: Development, QA, build machine, continuous integration server, software licenses, test data, any special hardware needed
  9. Task: Review the Sprint Ready checklist (see below) and take necessary actions so the Agile team will be 100% ready to start the sprint as soon as the Sprint Planning Workshop is over: ScrumMaster.
  10. Task: Complete all logistical arrangements for Sprint Planning Workshop (venue decided, attendees identified and invited, workshop material arranged, food ordered, etc.): ScrumMaster
 Sprint Planning Workshop Checklist

The checklist shown in Table 2 consists of a number of tasks (Tasks T1 through T14) to be completed during a Sprint Planning Workshop.  Rough time estimate for each task is indicated for a typical three-week sprint planning being done for the first time.  With process maturity, experience and well-jelled teams, this planning time should come down to ½ day for two-week sprint planning to 1-day for four-week sprint planning.

Table 2: Sprint Planning Workshop Checklist



Sprint Ready Checklist

This checklist consists of a set of tasks that must be completed before a sprint should start and can run smoothly.  If there is major incompletion of any of these tasks, it would be premature and risky to start a sprint, as it will experience obstacles, hick-ups, delays and impediments.

  1. Task: Sprint objectives are well defined: Product Owner
  2. Task: Full inventory of all work items is available, and all tasks and tests in stories of the sprint backlog are properly defined and  have proper estimates: Product Owner, ScrumMaster
  3. Task: Acceptance tests for each User story are well defined: Product Owner, QA tester
  4. Task: All Agile team members are identified, their roles defined and necessary training completed or plans made: ScrumMaster
  5. Task: Individual and total capacities and Individual and total estimated efforts match (for capacity-based planning): ScrumMaster
  6. Task: Various standards (coding, testing, documentation, build, user interface, compliance, etc.) for your project are defined and easily available: ScrumMaster, Team Leads
  7. Task: All IT environments, infrastructure and test sets required for the Sprint are available: ScrumMaster and IT staff
  8. Task: Work is distributed evenly across all members of Agile team (load balancing done): ScrumMaster
  9. Task: All stories in the Sprint are linearly rank ordered: Product Owner with Team
  10. Task: Sprint Done Checklist is well defined: Product Owner with Team
  11. Task: Any remaining small tasks that must be completed to reach 100% Ready state are documented (and are not show-stoppers): ScrumMaster

Daily Scrum Checklist

This checklist consists of a set of tasks for each individual member and also for ScrumMaster.  See specific details in my blog on Daily Scrum.

  1. Task: Ensure that the Daily Scrum room venue and timing is the same for every day in a sprint: ScrumMaster
  2. Task: Invite each member of the Agile team for Daily Scrum on a standing basis for every day throughout the sprint duration: ScrumMaster
  3. Task:  Prepare for the Daily Scrum meeting ahead of the actual meeting: Each team member
    1. Report on the status of yesterday’s tasks against the plan for yesterday
    2. Present the plan for today’s tasks
    3. Present what do I need from any other team members to do my work
    4. Present any impediments on the horizon that could block my work
  4. Task: Present key information radiators from APM tool, such as burn-down and burn-up charts, Cumulative Flow diagram, Impediments being worked on: ScrumMaster
  5. Task: Capture any risks, issues, and decisions coming out of Daily Scrum: ScrumMaster

Sprint Done Checklist

This checklist consists of a set of tasks that must be completed before a sprint can be declared successfully “Done”.  This list ensures unambiguous completion of a sprint.    

  1. Task: Acceptance testing completed: QA testers
  2. Task: Defect fixing work completed: Developers
  3. Task: Fixed defects are verified and closed by QA members of the agile team: QA testers
  4. Task: The list of defects to be pushed out to the next sprint is finalized: Product Owner, ScrumMaster, Team
  5. Task: All technical documentation is completed: Technical leads
  6. Task: All user documentation is completed and is ready to be released to sprint users: Tech writer
  7. Task: Sprint release can be delivered to interested customers and users ready to receive it: ScrumMaster
  8. Task: All data in APM tool is up-to-date and consistent with the completion (Done) state of this sprint: ScrumMaster and Team
  9. Task: Sprint delivery has met the Sprint objectives: Product Owner
  10. Task: Sprint release is accepted by the Product Owner: Product Owner

Sprint Retrospective Checklist

This checklist consists of a set of tasks that must be completed during Sprint Retrospective session (typically a 1 to 2-hour timebox) so that the team can develop a SMART action plan that it can act on during the next sprint to improve its own agile process in a specific way.  See specific details in my Sprint retrospective blog.

  1. Task: Determine up to 3 top things that worked really well, and the team wants to continue: Team
  2. Task: Determine up to 3 top things that were most problematic, and the team wants to discontinue or change: Team
  3. Task: Determine up to top up to 3 impediments and their root causes: ScrumMaster
  4. Task: Capture and present key statistics, such as initial capacity of the team, planned vs. actual velocity, scope change.  Most of these are reports generated by APM tool: ScrumMaster
  5. Task: Develop 3 to 5 specific action items as part of the Specific, Measurable, Achievable, Realistic, Time-bound (SMART) action plan to improve the agile process: Team
  6. Task: Convert the SMART action items into Stories in APM tool, and assign them to the next sprint: ScrumMaster

Need more information?

By no means, this is neither a complete set of all agile checklists nor I am suggesting that all agile development work can or should be captured into checklists.     However, you may think of several recurring activities with some degree of complexity as good candidates for checklists.  Some examples:  Daily Builds, Compliance and Certification Testing, Customer Trial and Evaluation Testing, Customer Acceptance Testing, Release Packaging, Delivery and Deployment, Customer Support Calls, etc.   Even the well-known INVEST criteria can be thought of as a checklist to make sure that stories in a backlog are Independent, Negotiable, Valuable, Estimable and Testable; and the SMART tasks within each story as another checklist for tasks that are Specific, Measurable, Achievable, Relevant and Time-Boxed.

Agile checklists can also be used as an effective mechanism to plan, coordinate, align and synchronize work across a larger number of agile teams on a large-scale agile project, such as a program or a SAFeTM release train of 5 to 10 agile teams working in synchronization on the same cadence, and a set of programs constituting an agile portfolio of several hundred people.   Dean Leffingwell’s book on Agile Software Requirements presents a very comprehensive Release Planning Readiness Checklist in Appendix C.  A Wikipedia section on Non-Functional Requirements (NFRs) gives a fairly comprehensive list of NFRs to consider.  You may use that list as a checklist to minimize the probability of overlooking or missing one or more NFRs while preparing and grooming your product backlog. The benefits of agile checklists increase even more when you want a large number of team members on multiple teams of a large-scale agile project to do their coordinated work in a consistent, standard way, and to avoid unnecessary variations among different teams and their members when there is no reason of or benefit from those variations.  Thus is the case because larger scale projects create additional complexity due to the need for aligning and synchronizing multiple teams in a program and managing a number of programs into a cohesive portfolio. An APM tool like VersionOne can make it very easy to templatize these checklists so all items within each checklist can be modeled as tasks and tests in a template; then those tasks and tests can be completed in a consistency way without errors across a large number of people and agile teams.  A team can have its own set of checklist templates, and projects and programs can have their own checklist templates, in addition to a standard set of checklist templates that are common for all members, teams, projects and programs in an enterprise.  If you are not yet using an APM tool that supports templates, don’t let that stop you from using agile checklists.  Try using Excel files on SharePoint or spreadsheet docs on Google Drive for creating and maintaining your checklists.  That will get you going quickly.

For additional information on agile checklists, you may find VersionOne agile checklist white paper very informative and imminently actionable.

Have you tried checklists on your agile project?  What is your experience?
Are you interested in experimenting with your own set of checklists?
I would love to hear from you either here or by e-mail ( or on twitter (@smthatte).

Categories: Companies

Error Monitoring Application Bugsnag Releases Assembla Integration

Assembla Blog - Fri, 04/18/2014 - 17:33

Bugsnag is a web and mobile error monitoring application that detects and diagnose crashes within your applications. They recently informed us about their new Assembla integration that can create Assembla tickets for detected errors allowing your team to quickly start squashing these errors via Assembla tickets.

To set up this integration, you will first need to have a Bugsnag project up and running. To try Bugsnag out, you can sign up here. From your Bugsnag project, visit the Settings > Notifications section to enable the Assembla integration. Once enabled, you will land on the integration configuration page that look like this:

bugsnag assembla integration

  • Determine when an Assembla ticket should be created: when the first exception of a new type (error) occurs, when a previously resolved error re-occurs, and/or when you manually click on “Create Issue” on an error within Bugsnag.

  • Space URL: Such as

  • Your API Key and API Secret: This can be created in your Assembla profile sidebar menu, or by following this link.

  • Tags (optional): This provides a default tag for all Assembla tickets created from Bugsnag such as “Bugsnag Error.” I personally love this part of the integration because with tag filters, you can easily see all errors that are being worked on and where they stand. To learn more about Assembla’s tag feature, check out our release announcement.

To learn more about other companies that have integrated with Assembla or to submit an integration for review, check out

Categories: Companies

Hard work is killing people. Literally!

Manage Well - Tathagat Varma - Fri, 04/18/2014 - 13:11
Burnout is a serious issue for several countries, industries and people, even if we don't acknowledge in as many words. In our industry, where heroism, cowboy programming and all-nighters are considered cool and an integral part of the software subculture, there has been a (really) small effort to address work-life balance.
Categories: Blogs

Leadership Dashboards: Post 2

Scrum Log Jeff Sutherland - Thu, 04/17/2014 - 20:45
This is the second post in a series about creating effective leadership dashboards.  You can catch the first post in the series on the goals of an effective agile dashboard here.
This post focuses on how to organize the creation of a great dashboard.  How the dashboard is created is often overlooked in favor of diving directly into what metrics to include, and the look and feel of a complete dashboard; but being deliberate in the process can dramatically improve the finished product and prevent the alarmingly frequent incidents of total failure.  For example, a client I am currently supporting in dashboard creation had previously worked with a large accounting firm to create an executive dashboard for their development group…six months and hundreds of thousands of dollars later, the project was cancelled without the leaders ever having seen a single working metric!
There are three main pillars for how to create a successful leadership dashboard:
  •      Use Scrum to develop the dashboard
  •      Develop a prioritized backlog of metrics and deliver incrementally
  •      Leverage an “interactive” interface and drill down hierarchy

Use ScrumIt should come as no surprise that I recommend using a Scrum team to develop and deploy the leadership dashboard. (After all, we use it for everything here at Scrum Inc.)  But interestingly enough, when most companies embark on developing a dashboard, they tend to treat it like an internal side project and not give it the full focus, attention and agile discipline that they apply to their customer-facing work.  With unclear roles and objectives, and competing with a dozen other projects for employee attention these informal efforts often go nowhere. 
If you are serious about developing a useful dashboard, designate a dedicated and cross-functional team to build it.  Maintain the discipline of working off a backlog of metrics to deploy and identify a product owner to incorporate user feedback. Leverage the structure provided by a regular sprint cadence with demo and retrospective meetings.  It may feel like a lot of overhead, but you will be glad you made the investment when enjoying your completed dashboard.
Deliver IncrementallyWhat caused the failed dashboard effort mentioned above, and countless others before it, was the attempt to deliver a working dashboard in a single “big bang.”  The hallmarks of this approach are to “mock up” the look and feel of all of the metrics in a dashboard, get buy in from leadership on that design, then build the dashboard.  Unfortunately, this waterfall approach is no more effective for dashboard creation than it is for software development, and for exactly the same reasons: 1) leadership doesn’t really know what they need to see to make effective decisions until they see it, leading to a “moving target” that can consume years of back and forth mock-up revision; 2) too often, teams agree on a mock-up only to discover that it is impossible to pull the data required to make it a reality; and 3) company data and systems are complex and interdependent…small changes to one element of the dashboard have ripple effects throughout the tool, making after the fact changes a nightmare.
Fortunately, dashboards lend themselves extremely well to iterative and incremental delivery. Each combination of metric and business unit within the company is a useful feature that can be delivered and refined independent of the other metrics.  Integration, summary views and second-order metrics can then be layered on.  A savvy product owner in dialogue with the dashboard’s end users can easily prioritize which metrics and which business units are of greatest concern and prioritize the backlog of metrics appropriately to deliver the greatest value as early as possible.  Ensuring that there is an easy way for users to provide feedback within the first iteration of the dashboard makes this process even more straightforward.
The biggest challenge here is to set appropriate expectations with leaders in advance about what incremental development looks like and get a commitment to providing feedback.  They might be resistant at first to a partially completed product or the effort of feedback, but it is imperative that they provide actionable guidance to produce an effective dashboard.  “It isn’t good enough yet” is a common response, but not sufficiently engaged and actionable to help the team. 
In the past, I have positioned the value proposition for incremental delivery as, “The initial version will be rough, and I can almost guarantee that you won’t like it; however: you will have something in your hands within x days, it will be REAL data that will improve your visibility over what you have now, and we will implement any actionable feedback you have over the subsequent iterations to make the dashboard exactly what you want it to be.”  This usually works, though it is worth getting agreement in writing for the inevitable retrenchment later.
Leverage an Interactive ToolThe default expectation in the business world is that a dashboard is a single page or PowerPoint file that contains summary metrics and can be transported around for easy reference.  While this is fine in practice, the advent of cloud computing and ubiquity of mobile devices have opened up significant new possibilities for interactive metrics reporting.  Here again, a little up front expectation setting is essential to leveraging this potential.
A single flat dashboard can only show top-level metrics and tends to get very cluttered as more information is added.  By contrast, an interactive data visualization tool like Tableau or Domo can have a clean and simple top-level design, but allow the decision-maker to click-down into disaggregated views as needed (stay tuned for more detail on tools in a future post).  It provides more data, but gives the user control over how much detail to show.  The data can be updated at different cadences or even in real time, rather than a single monthly update to a PowerPoint slide. Finally, with dashboards fed to mobile apps, the information is even more readily available than the printed dashboard page.
That said, remember that the dashboard’s ultimate purpose is to help leaders make decisions, so particularly in the early iterations it may be helpful to build a dashboard that looks familiar and comfortable to leadership.  Having built credibility in the process and team, you can then flex your interactive muscles and deliver value-adding capabilities.
In the next post, we will cover what information leaders typically want updates on a regular basis, and how to achieve those objective with compelling agile metrics. If you want a sneak peek at some of these metrics, they are covered in our online course on The Scrum Leader’s Dashboard.
Alex Brown is Scrum Inc’s Chief Product Owner and Chief Operating Officer.  He set up the company’s internal metrics dashboard to automatically consolidate and share agile metrics and support better decision-making.  He also trains senior leaders and consults to companies on how to succeed strategically in an agile business environment.
Categories: Blogs

Improved File Search: What You Need to Know

Assembla Blog - Thu, 04/17/2014 - 16:11

With the recent file search improvements, it is now easier to find the files you are looking for when you need them. With every file upload, we now index all the following elements: file name, tags, mime-type (media type), and author.

  • File Name: We now apply a word delimiter filter that splits words into subwords based on intra-word delimiters such as case transitions ("PowerShot" → "Power", "Shot"), letter to number transitions ("SD500" → "SD", "500"), and characters ("Wi-Fi" → "Wi", "Fi").
  • Tags: If you add the optional tags to a file, you can easily include a tag in the search parameters to locate the file.
  • Mime Type (Media Type): When a file is uploaded, it will be indexed with a media type such as hello.png will include “image/png” so it can be found with a search for “hello” or “image” or “png” or any combination like “hello image.” Almost all files have a mime type such as word, excel, zip, pdf, etc., and we now index them so you can locate your files easier.
  • Author: The author field consists of the user’s first name and last name as displayed in their profile as well as username. Usernames are also use the same word delimiter to split usernames into subwords. So if John Smith with username JohnRocks uploads a file, you can search for that file with “john” or “smith” or “johnrocks” or even just “rocks.”

Most importantly, the default logical search operation has changed to search for words using AND instead of OR when using a combination of words. For example, when you search “john image” it will return back anything that is an image AND that was uploaded by John.

We hope these improvements make file searching more efficient. If you have any other suggested improvements, please let us know on our feedback site.

Check out some other Assembla tips and tricks!

Categories: Companies

What’s So Special About Agile?

Agile Management Blog - VersionOne - Thu, 04/17/2014 - 15:19

SpecialButtonAdmit it.  You enjoy telling people that you’re an Agile “practitioner”, “coach”, or “evangelist”.

It’s OK – I do too.

I also enjoy reading a well-researched article in, say, the Harvard Business Review or the Wall Street Journal that validates what we do every day in the Lean-Agile community.  It shows that they want what we got (and sometimes, vice versa).

But I recently happened across the April 2011 issue of Real Simple magazine, the riveting theme of which was “Spring Cleaning”.  My curiosity as to how that subject could possibly warrant an entire issue led me to thumb through the pages until I came across an article entitled “This is Your Brain on Procrastination”, written by Amy Spencer.

The article presented the following list of things to do in order to get important things done around the house:

  • Do the worst thing first (you won’t have the energy to do it later)
  • Start your day over at 2:00 PM (assess and adjust regularly)
  • Make the job smaller (and do it just “good enough”)
  • Create an audience (make yourself accountable)
  • Race the clock (see how working in short, timed bursts affects your productivity)
  • Don’t interrupt yourself (or let anyone else do so)
  • Plan an unprocrastination day (prioritize and then immediately DO)

Sound familiar?  I thought so, too.

Yes, three years ago, guidance for which people still pay good money to be Agile-certified was published in an article on getting ahead on household To-Dos.  That tells me that maybe Agile isn’t so special anymore.

I think that’s actually a good thing.

Why? Because I noticed a long time ago that most of us tend to use one system of thinking at home, and another when we’re at work.  It’s almost as if we swap brains somewhere between the front door and the driveway.

For example, Home Brain says, “I have only so much money and so much time, so I’m going to have to accept the fact that I can’t have both a new refrigerator AND a new fence.”

Work Brain says, “Based on our best information, I know we can only really do the fridge. Tell you what: I’ll throw the fence in as a ‘stretch goal’.”  (Home Brain’s too smart for that.  He knows what stretch goals turn into.)

My efforts over the last several years, to a great extent, have been focused on simply getting people to take their Home Brains to work with them.  The addition, now, of even informal Agile thinking to Home Brain’s innate clarity and common sense will make it that much more valuable at work.

So what if Agile’s mysteries are being divulged to the uninitiated as they stand in the supermarket checkout line?   If value-oriented and throughput-focused thinking can permeate such mundane areas of our lives as decluttering a closet, then the the way we are trying to shape how we think at work will become more similar to how we think at home.

That should make bringing an Agile mindset into the workplace more natural.  I’m OK with that, even if it means Agile loses some of its status in the process.

Categories: Companies

How I Built WatchMeCode’s Subscription / Streaming Service

Derick Bailey - new ThoughtStream - Thu, 04/17/2014 - 13:30

In my last post, I talked about the events leading up to and the events of launching WatchMeCode‘s new subscription service for JavaScript screencasts. In that post, I very briefly mentioned using WordPress and some plugins and add-ons to get the service up and running in a matter of hours – what would have taken me weeks or months to do if I were writing all of the code from scratch. Several people have asked about this setup, so I wanted to share more detail about what I’m using.


I chose DigitalOcean as the hosting for the service. It’s cheap and seems to be very robust. I’m using it for both this site ( and WatchMeCode, both with separate server instances. John Sonmez says that he runs around 100,000 visits a month from the $10/mo server with DigitalOcean. I believe it. I also set up the $10/mo platform, using Ubuntu


I’m served up about 5,000 views during my launch week for WatchMeCode, and here are my stats for bandwidth, disk and CPU usage for that week.


As you can see launch day had a MASSIVE spike in CPU at 4.89% … this is definitely a rock-solid setup. I highly recommend DigitalOcean for a setup like this.

WordPress + StudioPress

The core of the site is built on top of WordPress. I’ve used WordPress in the past, but not extensively. To get me rolling, I used John Sonmez screencast on how to set up a WordPress blog with DigitalOcean, from his How To Market Yourself As A Developer course. I know there are plenty of blog posts and other things out there, but this was a resource I had and I was able to follow it step by step to get everything done. 

In addition to WordPress, I chose to buy a theme from StudioPress. After doing some research, I found the Genesis framework to be particularly appealing. It adds a lot of things that I want to a core WordPress install, and makes it easy to buy custom themes that can be further customized very easily. 

The site design and content are managed through pages and blog posts for the most part, with a few things being hard coded in to Text widgets – but not much. 

Restricting Content To Subscribers

To manage subscribers for the site, and to allow me to easily show and hide content for subscribers vs non-subscribers, I chose Restrict Content Pro. Through a simple set of short codes, combined with various settings on each individual post and page, I can restrict what content shows up in the RSS feed, show certain things to subscribers and other things to non-subscribers, and easily customize the way this works. 


I bought the big $ package of RCP so that I could get the Stripe integration, and it was well worth the extra money. Paypal is nice, and a lot of my subscribers use Paypal. But I really do prefer Stripe. 

Hosting And Playing Video

The majority of my videos are hosted via Amazon S3. I bought the S3 Media Maestro plugin to handle these (you can see the “s3video” short code in the above screen shot). S3MM also gives me the file download links.

This is a great plugin because it lets me have secure (private) files in S3 storage, but still make it possible for subscribers to watch the videos. S3MM handles creating the pre-signed URLs for the media, and provides the MediaElement.js player as the video player for the files. 

My free videos are uploaded directly to YouTube and I use a YouTube plugin for WordPress to embed them in the pages.

Other Plugins

There are a handful of other plugins that help to make things simple, as well. Here is my complete list. You can get the idea of what each of these other plugins does for me, just through the description.


Definitely Worth The Time And Money

In spite of my initial hesitations (months worth of hesitation… ), I found my experience in building this setup to be quite enjoyable. It took me less than one day of work to go from nothing to having a complete subscription service with my first screencasts secured and available. Of course it took a lot longer than that to finish filling in all my content, tweak the site design and add the videos… but that was the work I wanted to be doing. I didn’t want to spend weeks or months building a service that would handle these things. I wanted to get the service launched, have it done well, and be able to focus my time and attention on the content and videos. Having a WordPress setup with all of these plugins available made that possible.

     Related Stories 
Categories: Blogs

No Magic Words

Agile Coaching - Rachel Davies - Thu, 04/17/2014 - 11:45

I gave a talk at Agile Coaches Exchange meet up yesterday and someone emailed afterwards saying

"Rachel mentioned about few questions that she  uses during one on one. Those set of questions could help me a lot because I am terrible to start and flow the conversation with my team."

So I thought it might be handy to do a quick write-up of what questions I tend use in individual coaching sessions.  

Well just to be clear, I don’t follow an exact format or set list of questions -- I’ve been coaching for so long that questions seem to come burbling out of my mouth without much premeditation or forethought. Here's what I think I ask but this might actually differ a lot depending on the person or current issues.

Before we head off to our meeting, I check “Is now a good time for you?” and I’m fine to move to another time or skip the meeting. Coaching is always optional. 

Once we sit down, I tend to start with open questions like:

  • “How are you doing?”
  • “Are things going well at the moment?”
  • “Are there any issues you want to discuss?”

This tends to open out topic areas that we kick around -- discussing root causes , trying to see events from other perspectives and identifying possible courses of action.

I also look back in my notebook to see whether we talked about any specific issues at our last meeting:

  • “Last time we discussed pair rotation in your team, is that working better now?” or
  • “You facilitated a retrospective for the ABC team last week, how do you think that went?”

If they led a meeting, I ask if they’d like any feedback from me.

I might also mention current events such as team or process changes:

  • "We have a new developer joining your team next week, have you thought about how she's going to get to know the system?"
  • "We've changed the story time meeting format to run it with both teams together, how do you think that's working out?"

If the conversation dries up then we move onto specific areas such as personal development:

  • “What research projects/Gold Cards have you been working on lately?”
  • “Got any plans to give a lightning talk about that next week?”
  • “You mentioned that you were planning to submit for XYZ conference, have you sketched out an abstract?”

I usually check at the end “Are there any other things you wanted to discuss?” and let them know that I’m around to discuss further any time.

There are no magic words or special incantations that I’m aware of. The main thing is to focus on what the other person has to say and try to listen carefully to what they’re experiencing and changes they wish for. I care about whether they’re happy at work and hope that talking will help them stop worrying about things that are holding them back and start acting on their concerns and ideas.

Categories: Blogs

Targetprocess 3 Launches to Bring Visualization and Flexibility to Project Management - Thu, 04/17/2014 - 11:08
Targetprocess announced the availability of Targetprocess 3, which now includes more ways to visualize project data, track work across multiple teams and align business initiatives with development. This latest release reinforces Targetprocess’ dedication to offering a project management s ...
Categories: Communities

Targetprocess Version 3 Launched

Scrum Expert - Thu, 04/17/2014 - 11:00
Targetprocess announced the availability of Targetprocess 3, which now includes more ways to visualize project data, track work across multiple teams and align business initiatives with development. This latest release reinforces Targetprocess’ dedication to offering a project management solution that improves visualization and flexibility, ultimately allowing organizations to make smarter, more efficient decisions. As today’s businesses continue to evolve, the tools that cater to them must do so as well. Targetprocess was created with the goal of bringing visibility into management and this concept has catapulted them as one of the ...
Categories: Communities

Top Ten Signs That Your Product Manager Isn't Agile

Applied Frameworks - Thu, 04/17/2014 - 04:11

Blog Editor's Note: This post originally appeared in late 2008 when we were Enthiosys. I'm very interested in whether anyone else agrees that the list still resonates. Enjoy.

Originally Published October 20, 2008

Here at Enthiosys [now Applied Frameworks] we spend a lot of time helping Product Managers become Agile. In the process, we often run into developers who are really frustrated with their Product Managers' lack of Agility. Acknowledging their pain, here are our top ten ways to tell if your Product Manager doesn't understand Agile. And yes, it was hard to whittle down from the 40+ items on our initial list.

10. She says "I think" instead of "the market research says" or "during our last review meeting with a customer…".

9. He thinks release planning can be done in 2 hours.

8. She sometimes attends an iteration planning meeting, and rarely (or never) attends an iteration acceptance meeting.

7. He thinks the backlog is just the list of market problems he captured in his MRD.

6. She doesn't have a roadmap beyond the stories in the next release.

5. He thinks MuSCoW works when prioritizing the backlog.*

4. She can't provide acceptance criteria during release or iteration planning.

3. He stops visiting customers so he can attend every daily standup. Even worse, he talks about his tasks during the daily standup.

2. She thinks that year-old market data is good enough for managing the backlog or developing a roadmap.

1. He thinks a product owner is a Product Manager.

*MuSCoW is a way to organize requirements into buckets of "Must, Should, Could, Would".

Categories: Companies

Grasping Agility: Agility, Personality and Failure

Danube - Thu, 04/17/2014 - 00:50

I’ve never been much of a blogger. The concept of short but frequent commentaries on subjects causes the perfectionist in me horror.  I hate failing on a deep visceral level. Even my small failures tend to cause me distress for weeks or months after whatever the mistake was.

 Agility, Personality and Failure

My personality tends to stop me from starting things that may fail, but others deal with failure in other ways. Some try to hide the failure, others deny that a failure is actually a failure and continue to go along without making any sort of correction.

In business today my personal preference for failure avoidance is typically not an option. If we don’t do anything we don’t make money and we are probably involved in defrauding investors somewhere along the line, so we will just brush that one aside for the moment. The other two are the ones that I would like to address, because these are what Agile and very specifically Scrum looks to help us overcome.

This difficulty often results in failure, as it should. Sadly the reaction to this failure is all too often; “We can’t do this” when it should be “How can we make this work”. The software industry has clearly demonstrated that Scrum is not only possible, but optimal. There is no business that Scrum could not be applied to successfully (should it be applied is another debate).

In truth, dealing with the problem of an organization trying to hide failure is a simple one, all you have to do is practice Scrum and everything will surface. Dealing with the denial of failure is a bit trickier.

In most software organizations we are conditioned to be horrified by failures because in a traditional waterfall structure they are catastrophically expensive. At best we have lost months of work, and at worst, years. Scrum allows us dramatically reduce the impact of these failures by taking them to a place where we have lost 2 weeks at most, or more typically a day or two. The trick is that even though these failures are not costly, our reaction to them is the same as if they had been. We don’t see them as the valuable knowledge growth they represent;  we see them as the end of the world.

In any sort of bureaucracy the instinct to hide or deny is strong, but if we can bring people around to an understanding that failures are simply part of the normal course of business, to be learned from and used to drive adjustments, we can start to overcome the denial.

In the end it is all a culture shift. Adopting Agility in an organization requires self-reflection, asking ourselves why we react as we do to failures. Admitting that aspects of our business that we just assume to be “normal” are actually failures and should be addressed comes with this. It’s a frightening thing to put together a proper list of impediments to success, but a necessary one.

Scrum shows us what is wrong, but we still have to fix it. The final, and most important piece of this is understanding something that years of conditioning has destroyed in most organizations; Just because something is broken doesn’t mean we have to fix it today, or ever. Part of why we hide, avoid, and deny failure is because we think that as soon as we know about it we have to fix it. Not true, not even possible in most cases. We have years, decades even, of problems to resolve, it’s going to take a while, but if we don’t dredge them up, admit to having them, and work out a plan for fixing them, they never will be.

The post Grasping Agility: Agility, Personality and Failure appeared first on

Categories: Companies

Retrospective activity (filtering) : Most Likes and Dislikes

Agile Tips - Wed, 04/16/2014 - 22:57
cross posted on

This is a follow-up on the Plus Minus Voting activity. It creates a visual tool for the marked items according to its total score (from the lowest to the highest).

Running the activity
1. Create an axis as per the figure below (<- -="" minus="" plus="" zero="">).
2. Ask the participants to place the marked post-its (from the Plus Minus activity) on the axis as per their total score (e.g., 4 + and 1 – have a score of 3).
3. Discuss with the group about the items.
Note that the items with + and – on it represent items in which the participants have different opinions.
I find this activity specially useful for cleaning up the canvas. The post-it with most votes are picked up and moved to a new place. By doing this, the participants are naturally filtering out the notes. Some colleagues have added an extra dimension (an Y axis) for counting the total number of votes (picture below).
Copy of most-likes-and-dislikes-Yaxis
Categories: Blogs

Five links on Agile requirements

User stories also fall into the all too common trap of defining a solution instead of presenting problems to the team






I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!

Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: Please follow @agilequote for more quotes.

Categories: Blogs

Six Signs your Team’s Acceleration is Too Good to be True

Scrum Log Jeff Sutherland - Wed, 04/16/2014 - 19:56
Let me say right from the beginning that I am a hugefan of tracking velocity in Scrum…it is an amazingly powerful concept. 
  • The ability to measure team output from sprint to sprint allows a team to systematically experiment with different process improvements and consistently get better over time. 
  • A clear sense of how much output the team actually produces within a sprint also drives better decision-making about when to expect project completion without slave-driving the team developing it. 
  • As an agile leader, I like to know whether my teams are accelerating, decelerating or staying stable over time. If they are accelerating, it gives me confidence that our projected completion dates are relatively safe; whereas if they are stable or decelerating, it implies greater risk in current projections. 
But metrics are only as good as the integrity of the data that feed them. The traits that makes estimating velocity in points so powerful (speed, ease for the teams, intuitive accuracy of estimation) also mean that, in the wrong conditions, velocity can be manipulated to produce misleading conclusions.  To be clear, this is not the terrible scourge that proponents of measuring in hours often claim it is…a few simple guidelines such as “NEVER tie incentives to velocity” and “don’t use declining velocity as a reason to beat up your teams” generally suffice to eliminate any deliberate gaming of the system. 
However, seeing velocity increase over time just feels good and teams often thrive on the sense of accomplishment that comes from getting more done in less time.  Even without overt pressure to increase velocity, the collective will to go faster can create upward velocity drift that isn’t necessarily driven by increases in underlying output.  Since only the team suffering from velocity drift is impacted, this need not be a major problem. But for Scrum Masters, Product Owners and teams concerned with maintaining the integrity of their velocity metric, I humbly offer…
The 6 signs that your beautiful velocity growth trajectory may just be bad data:
  1. Velocity alwaysincreases – Even the highest-performing Scrum teams suffer setbacks or encounter new impediments.  In general, scrum teams that set challenging goals should expect to fail about 20% of their sprints, meaning that velocity should decline from the previous sprint about the same percent of time (if you are using “yesterday’s weather” to pull stories into the sprint). If your team has been through a dozen sprints without a single backslide in velocity, it suggests that stately upward trend is being managed more deliberately than it should.
  2. Inexplicable Acceleration – Velocity can go up in short bursts for no particular reason, but it is difficult to sustain structural velocity improvement without systematically removing team impediments.  So if a team’s velocity has been increasing consistently but they can’t point to specific impediments that they have removed, that is a red flag that the acceleration may not be real.  At best, the team is not conducting healthy process experiments to deliver repeatable and sustainable acceleration.  At worst, they may be undermining the meaningfulness of their velocity.
  3. The same story now receives a higher point estimation than it used to – This is the definition of “point inflation” that opponents of measuring velocity in points are always pointing to.  In practice, we rarely see egregious cases of point inflation where the exact same story that was 3 points in a previous sprint is now 5 points in the current one.  Instead, we typically encounter more nuanced forms of inflation, such as when an additional quality check is added to correct for past issues and points are added to complete this additional work.  The amount of effort needed to complete the work may have increased, but the amount of output has not, so these added points represent a subtle form of point inflation.
  4. Backlog stuffing with “filler stories” – Teams that are striving to increase velocity often become obsessed with ensuring that everything they do is reflected in the backlog.  In general, you don’t want to do tons of off-backlog work and do want to stay focused on completing the goals of the sprint. However, some level of housekeeping and team hygiene work is a natural part of the group process.  If including these items in the backlog was always a team norm…that is fine. If that wasn’t always the norm, then including these filler stories with associated points gives the false impression that the team is accelerating when it is not actually producing more output.
  5. Lots of separate minimum-sized stories – We often say that smaller user stories are better, and that ultimately teams should strive to work with uniformly small stories in the sprint.  This is a great goal, but it can be taken too far.  If work is broken into many stories that are smaller than the smallest sizing increment used by the team (“xs”, “1-point”, “Chihuahua”, etc.) then the rounding error of adding all these fractional stories together starts to exert a strong upward influence on velocity.  If these precisely divided stories are still good user stories reflecting incremental functionality, then it is time to reset your reference story to accommodate smaller divisions.  More often than not, however, these tiny stories are really tasks and are hurting the team’s ability to work together to produce quality product.
  6. Excessive “normalization” of velocity – Tracking team strength in each sprint is helpful for knowing the context the team is operating within. There are a number of compelling reasons to apply a lightweight level of normalization to a team’s raw velocity number to get a better predictor of actual team output: it provides a more stable measure of output in the face of major illness, vacations, family leave and other significant shifts in team capacity.  However, it also introduces one more lever that can artificially increase apparent velocity, so teams need to be careful to only reserve normalization adjustments for major capacity impacts, and not try to adjust for every perceived shift in team strength.  If you notice that the team has not been at full capacity for a long time, it is time to questioning if over-normalization may be occurring.
I    Feel free to share your own experiences with velocity in the comments section below, or check out other musings on the value of good metrics in Scrum, including a thread on leadership dashboards here.


Alex Brown is Scrum Inc’s Chief Product Owner and Chief Operating Officer.  He set up the company’s internal metrics dashboard to automatically consolidate & share agile metrics and support better decision-making.  He also trains senior leaders and consults to companies on how to succeed strategically in an agile business environment.
Categories: Blogs

Does Pair Programming Have to Suck?

TV Agile - Wed, 04/16/2014 - 18:49
On some Agile teams pair programming is the norm; developers enjoy the collaboration and experience enhanced productivity. Others, though, work on teams where pairing is shunned, avoided, or just faked. Why do some craftsmen thrive with pairing while others want nothing to do with it? Why does coach-enforced pairing turn into something dry, distracted, imbalanced […]
Categories: Blogs

Heartbleed Update: LeanKit Service Provider Status

Update 04-21-2014: LeanKit service provider, Akamai, mitigates vulnerabilities. Users advised to change LeanKit account password(s). Learn more ********* Initial checks with all of our vendors indicated that there were no LeanKit service provider vulnerabilities to Heartbleed. However, our content delivery network (CDN), Akamai, recently amended their previous statement to communicate to their customers that they are currently implementing […]

The post Heartbleed Update: LeanKit Service Provider Status appeared first on Blog | LeanKit.

Categories: Companies

How To Thrive As an Agile Tech Writer

Rally Agile Blog - Wed, 04/16/2014 - 13:00

Ah, tech writers. We do more than tell the user how something works -- we also explain the caveats and intricacies behind why a feature or enhancement functions the way it was designed. It’s a tech writer’s job to learn and communicate the value of any software we deliver to customers.

Since our Rally Help site contains over 1,000 pages of content, it’s imperative that we interface with other teams on a predictable cadence so we know what needs to be updated or refined. Our content also relies on the feedback we receive and our customers’ expectations that they have the online help they need at their fingertips.

Over the past year our User Learning team has worked hard to become a highly productive, relevant, and visible team that is responsive to customer needs and expectations. Here are a few examples of challenges we've met and solutions we’ve provided.

Challenge: Our customers need more than written help

Solution: Give them what they need!

Our team creates written content, videos, and tutorials to cater to many different learning styles. Last year, we decided to create a new type of content: GIFs. GIFS are a dynamic way to show what it looks like to use a new enhancement or navigate to a specific place.

When you think about it, who has time to read through extensive documentation? Any time we can create a GIF that shows you how to do something in less than 10 seconds, we do it!

For example, here’s a GIF that shows you how to mark a card on a board as ready to pull or blocked:

blockreadyreason (1).gif

Great end-user documentation is much more than mandatory written instructions. Breaking content into easily consumable bites and leveraging technology like GIFs and video is critical. Whenever our customers need to gain an understanding of new functionality, our team works to create easily consumable content.

Challenge: Our team is the last to know about a new feature or enhancement

Solution: Collaborate early and often

When a feature or enhancement is released, the work of tech writers is often viewed as an afterthought. After planning, the product owner should be able to provide the tech writer with a timeline and enablement information for a new feature or enhancement.

So our team reaches out to product owners for details on business value, timeline for release, and user enablement on at least a weekly basis. We also get invaluable input from our user experience team, developers, and testers concerning issues that users may encounter with a new feature or enhancement.

We attend weekly feature status meetings and occasionally sit in on another team’s standup if a large feature is coming out soon and frequent changes might affect our documentation or videos. We also lead weekly meetings for other teams to learn about upcoming releases and review recently updated documentation.

This visibility with other teams has greatly increased our preparedness when documenting new features. Plus, we get the added bonus of seeing how the feature evolves week-by-week before it’s released to our customers.

Challenge: Feedback is second-hand, and mostly internal

Solution: Give customers the opportunity to provide direct feedback

While our team has received great feedback about our Help site from people who work here at Rally, we realized we were missing something: direct feedback from our customers.

That’s why we implemented a feedback form on all pages of our Help site. We receive daily feedback and we read each and every message we receive. Yes, reading through all of these messages takes time, but it has opened our eyes to who is using our content and how they use it, as well as helped us identify gaps in our content.

This direct customer feedback has been critical to improving our content. Our users have contacted us about everything from broken links to clarification about the functionality of a burndown chart.

Over the past year, our team has learned how to engage both the internal and end-user consumers of our help content. Now, instead of being an afterthought, the content we create is an integral part of creating value for other Rally teams and our customers.

Erika Edwards
Categories: Companies

Scrummaster is not a proxy

Silver Stripe Blog - Wed, 04/16/2014 - 12:32

Here is a pattern that is commonly seen in teams — the scrummaster acting as the point of contact for a team. What does that mean?

  • When the PO has a question, they ask it to the SM and expect them to relay it to the team. When the team member has a question to the PO, they tell the scrummaster and expect them to ask it to the PO.
  • In conference calls, the SM is the one who does most of the talking. If there is a question from a team member, they ask the SM and the SM (who is near the phone) asks it in on the call on their behalf. Likewise, if there is a question from the other end, then SM relays the question to the team or team member, then relays their answer back on the call.
  • The SM represents the team when attending the Scrum of Scrums, status report calls, calls with management and others such meetings
There might have been many other situations where you might have seen the SM acting as a proxy or point of contact between the team and someone else. Being a scrummaster does not mean being a proxy for the team. A good scrummaster will enable the team to self-manage. That means, leaving the team to take charge, and stepping into the background. So:
  • If the PO has a question, they either ask the team directly, or if they are not colocated, then send it to the team distribution list so that any one of the team members can respond. If a team member has a question to the PO, they ask directly to the PO without routing it through the SM.
  • In a call, the SM steps back and the team interacts directly with whoever is on the other side
  • Send a team member to represent the team for Scrum of Scrums or management calls. Teams can even rotate the team member they send. In a good team, every team memberknows where the team is, where they are going and can represent the team.
The SM only steps in if there is some dysfunction happening, for example a discussion goes off topic and needs to be taken offline or put on a parking lot. So what do you do if you are a Scrummaster and other people assume that you are the point of contact? At that point, you need to gently remove yourself from the middle.
  • If a team member has a question to the PO, encourage them to email / lync / skype the PO directly. They can update the team after their discussion (if the team members sit together) or at the standup
  • If someone asks you a question directly, forward it to the team DL and encourage them to send future questions there next time. Then leave it to the team to answer the question. Step in only if no one is answering it assuming that someone else will do it (the whole team sitting together helps).
  • During calls, make sure you are not sitting anywhere near the phone :) Similarly, in meetings, take an inconspicuous position near the corner of the room or sit on the floor.
  • Rotate between team members for representing the team in reporting calls with management or others
In some teams, the SM is also an engineer on the team. In such cases, the SM has to carefully switch between playing a facilitator role and a team member role. You may have to switch hats multiple times. Remember which hat you are wearing and play the role accordingly. The goal of the Scrummaster is not to manage the team, but to help the team become self-managed :)
Categories: Companies

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.