Skip to content

Feed aggregator

Assembla & Slack Integration How-To

Assembla Blog - Tue, 07/15/2014 - 14:23

If you use Assembla and Slack, we have added a pre-configured webhook making it easy to post Assembla events out to your Slack chat room/channel. Check out below for configuration instructions.

To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.

Once installed, click on the Webhook tool in your main navigation and select Slack from the list of pre-configured post options:

Slack Assembla Webhook

You will need to setup an incoming webhook service integration within Slack to obtain your token. To do this, visit, select the desired channel to post to, and click ‘Add Incoming Webhook.’

describe the image

Once created, copy the provided Webhook URL and update the External URL in Assembla’s Webhook tool.

Now configure what Assembla events you would like to post to your Slack room/channel and click ‘Add and Authenticate.' Don’t forget to enable the configuration under the “Title” field.

Tip: Within the Slack “Incoming Webhook” page that you set up for this integration, you can scroll to the bottom of the page and expand the “Integration Settings” where you can add a label, change the post-to channel, and change the icon and name for your webhook bot.

Your Assembla events will now be posted to the configured Slack room/channel:

describe the image

If you have any questions or problems during setup, please contact If you do not have an Assembla project and would like to test out this integration, try Assembla out for free.

Categories: Companies

Assembla & HipChat Integration How-To

Assembla Blog - Tue, 07/15/2014 - 13:40

If you use Assembla and HipChat, we have added a pre-configured webhook making it easy to post Assembla events out to your HipChat chat room. Check out below for configuration instructions. 

To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.

Once installed, click on the Webhook tool in your main navigation and select HipChat from the list of pre-configured post options:

HipChat Assembla Webhook

You will need to obtain and update the auth token and room ID in the “Content” section.

To obtain your HipChat auth token:

You will need to visit and enter your password to access the “API Auth Tokens” page. Under “Create new token” select ‘Notification’ type, provide a label, and click ‘Create.’ Copy the token ID and replace the “HIPCHAT_AUTH_TOKEN” in the Webhook tool.

describe the image

To obtain your HipChat room ID:

Visit and click on the desired room you would like to post Assembla events to. Copy the App ID and replace the “HIPCHAT_ROOM_ID” in the Webhook tool.

describe the image

Now configure what Assembla events you would like to post to your HipChat room and click ‘Add and Authenticate.” Don’t forget to enable the configuration under the “Title” field.

Your Assembla events will now be posted to the configured HipChat room:

HipChat Assembla Example Chat

If you have any questions or problems during setup, please contact If you do not have an Assembla project and would like to test out this integration, try Assembla out for free.

Categories: Companies

[Webinar] "Fast IT": Concepts and Examples from Assembla and Attivio

Assembla Blog - Fri, 07/11/2014 - 17:41

Join us on July 23, 2014 from 11:00 AM - 11:45 AM EDT for a webinar “Fast IT”: Concepts and Examples from Assembla and Attivio.

describe the image

When we at Assembla heard about the 2-2-2 project structure used by Attivio, we knew we had a fun story and a big idea to share.  The fun story is the way that Attivio can spin-up major Business Intelligence apps with 2-day, 2-person prototyping sessions. The big idea is “Fast IT”: a way of managing fast and Agile projects, while working smoothly with your slower, more reliable core systems: "Core IT".

In this Webinar, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla, will share their discoveries about ways that “Core” and “Fast” can work smoothly together.  We will show tools that help you wrap and index your Core IT so that you can easily use it in Fast IT projects.  And, we’ll show how to professionally launch and manage an expanding portfolio of Fast IT projects for analytics, Web, mobile and marketing applications and SaaS integration. 

This Webinar is designed to help IT professionals or project managers who are handling analytics, Web, mobile, cloud and marketing applications.

describe the image

Presented By:

assembla logo rectangle    Attivio logo

Categories: Companies

Good Enough Software Design? Try Testing DX of your Code

Agile Coaching - Rachel Davies - Fri, 06/27/2014 - 17:59

Every day writing code we make many design decisions about naming and encapsulation of functionality. Our primary concern is to express our code in a way that can easily be understood at a later date so changes can be made cleanly. To this end, we've learned to organise our code into smaller elements that can be composed neatly to support system behaviours, as where code gets complicated misunderstandings can happen.

When trying to figure out code quality, developers normally lean on software to analyse code complexity and test coverage. Perhaps we might learn more about how good our design is by starting to apply techniques from UX to measure DX (Developer eXperience)?

Developers are primary users of our software design, often working across a vast and complex codebase that's difficult to navigate around. Sometimes our code terrain is too crowded with repurposed junk and other times it's hard to see the wood for the trees with no easy landmarks to navigate by. We could start to measure how easy the code is for developers to navigate. How long does it take a developer to pinpoint the location of code to change? How many places do they look before finding the relevant areas to change? etc.

My interest in DX was rekindled by a recent discussion at SoCraTes on “What is good software design?”.  I sighed inwardly when the topic was chosen by the crowd and if I hadn't been on facilitator duty, I'd probably have skipped the discussion entirely. How wrong I was! I’ll try to sum up the highlights and link to some earlier thoughts I had on topic of DX following a talk at London's Design Museum on the usability of Underground maps.









 We ran this evening discussion as a Fish Bowl — you can only comment on the discussion topic, if you are in the 'bowl' — 4 chairs at the front. One chair is always kept empty, to allow anyone in the room to jump in with a question or share some relevant information. The "fish" in this photo are: Chris Jeffery, Mashooq Badar, Steve Hayes but many people jumped in and out of our conversation. Here are some of the points that I found most interesting:

Design is how we layout the code to make it easy to maintain. It may appear that there’s no external impact of software design and it's pretty intangibe how we evaluate one design over another. However, there are measurable external affects on staff retention, ease of change and developer mood. Corey Haines has been working on Mercury App, a tool which can be used by a developer to track their mood over time.

Steve Tooke mentioned Sandi Metz's TRUE criteria for design judgement

  • Transparent
  • Reasonable
  • Usable
  • ExemplaryMeasure

We talked about designing for use and as developers are primary users of our code perhaps we should think more about the developers who come after us. Brian Marick has summarised good code as that which brings joy to those who come after (users and programmers). Maybe we can aspire to bring joy to developers who read our code months or years after we write it! We could apply techniques from UX practitioners to start measuring accessibility and navigability of our codebases. We could use our findings to identify worst pain points, bringing focus to our cleanup attempts and measure whether working conditions have improved through user testing. Dmitry urged us to "Track everything that developers do!"

And Anna Jayne added via #SoCraTesUK twitter stream that we already sort of do in WTFs per min!

All this reminded me that I had some similar thoughts about measuring DX last year. My fascination for maps took me to London’s Design Museum to hear a talk by cognitive psychologist, Maxwell Roberts, who has been measuring the effectiveness of different layouts of underground maps. I thought the same approach might be used to assess the accessibility of different software designs/architectures, sort of UX from a programmer perspective.

I also heard at SoCraTes that DX of API’s is already being tested see this post from Pamela Fox and Jeremiah Lee has also run some workshops on DX at SXSW and Fluent conf

At the Design Museum, Maxwell talked about "information pollution" and how we want to reduce cognitive load for users in processing what they see in front of them. It also helps if a map doesn't significantly conflict with their mental model of the actual topography of the city. Clearly cognitive load must be a big factor in understanding the software design, as we try to figure out where to insert behaviours into a software system. Although we try to use meaningful names to help make code self-explanatory perhaps when a developer is confronted train wreck of long names in a literal programming style iit actually makes it harder to see the structure than using shorter names. We could test this kind of thing using DX.

Also the comparison of a underground map and city topography (people find London underground map easier when the Thames river is shown) might be similar to the software architecture/metaphor matching to real-world domain.

Maxwell's point was that people often use same design rules without thinking about whether they are the best possible for the problem. He's a proponent of a UX technique - Evidence Based Information Design and has been doing testing of different underground map designs for the same city (octolinear/hexalinear vs curves, etc). He takes objective measures: how long does it take a user to do X? Where X might be station finding or journey planning. He also takes subjective measures: how to users rate the map? which map would they choose?

His findings are interesting. Subjective measures on aesthetics don't correlate with which map is quicker to use. People like designs which seem familiar even though tests show that other designs are quicker to navigate. I thought of how conventional/familiar coding styles put developers at ease even though actual design may be a bad fit for a problem.

His design principles for maps were:

  • Simplicity
  • Coherence (shape/structure)
  • Balance
  • Harmony
  • Topography alignment
  • Reduce supplementaty info

When we create maps we want to map topography and reveal structure but we may need to discard current conventions to do so. We should beware following tradition without theory about why it's being applied to this particular problem. For underground maps, people are too hooked on octolinear style (following early success of London underground map in 1930's) but other styles are better for different city geographies. Perhaps in software development we are too used to OOD conventions to see that this can obscure design.

One of the last points made in our discussion at SoCraTes is one from Christopher Alexander, whose work on architectural patterns inspired many software developers to mine design patterns for software. Apparently Alexander’s advice to the software community at an OOPSLA conference was “Don’t extract the humanity” and perhaps by starting to test DX this could be a start of putting developers to the forefront of evaluating good design practice. Let’s try to write better code for the developer who comes after us by testing developer reactions now.

Categories: Blogs

Success Story: GLG Boosts “Customer Equity” with Assembla

Assembla Blog - Tue, 06/24/2014 - 17:25
GLG Logo Challenge

Garrigan Lyman Group was worried about losing the loyalty of its own customers. The agency was expanding rapidly and tackling more complex e-commerce, mobile, social media and video projects. Clients had no visibility into when new requests would be delivered. Development managers were having trouble tracking releases and matching resources to requirements. Teams needed a solution to prevent missing deadlines and ensure the quality of delivery.


Chris “Whitey” Geiser, GLG’s CTO, knew that the agency could not afford to lose “customer equity,” the hard-won confidence that GLG could deliver innovative digital marketing solutions. So he and his team began looking for technologies that could help them centralize processes, manage development requests, and improve communications with clients.


Assembla has helped Garrigan Lyman Group win new business from existing clients. The solution has helped GLG evolve from helping clients with flashy but self-contained marketing projects, to solutions that work with the core of their businesses. It allows the company to collaborate better with clients and improve control of their development processes.

To see how GLG learned to work more closely with its customers,
fill out the form below to download the full case study.


Categories: Companies

The Folly of Scaling Agile

Agile Coaching - Rachel Davies - Thu, 06/19/2014 - 17:37

I’m jotting down a few notes on Scaling Agile software development as Bucharest Agile group invited me to talk about doing this. I have already warned them that I am very skeptical about attempts to apply agile practices on large endeavours. While preparing for our conversation, I thought it might be helpful for me to blog about the reasons why I’m not a fan of Scaling Agile as this may make our conversation easier to follow and help the group to come up with some questions.

When we apply Agile principles, we strip away process so that software developers can work more collaboratively with business people to identify what is the most valuable thing for them to deliver next. We focus on building working software and releasing as early as we can to help us figure out what to build based on feedback from users. Working this way is much harder when a lot of people are involved!

A bunch of things break down as you scale up. The biggest one is not being able to maintain interpersonal relationships through which rich information flows, these are replaced with weaker lossy forms of communication and misunderstandings about what is the right thing to build next follow.

Typical things that become difficult at scale are access to business people and infrastructure controlled by others outside immediate team. Meetings get long and tedious, we start sending a representative from each team, which introduces more secondhand information, emails and documentation.

When a project is big and is being changed by many hands it becomes much harder to understand the whole, we start to introduce hierarchy with a select few looking at the bigger picture and paying attention to separating concerns to allow different teams to work in parallel. As a result, choice is removed from the team and it can feel in teams that edicts come down from on high through a series of chutes and screens that mask the reasoning behind them.

Often the initial attraction of Agile approaches to a business is to reduce delivery timescales and enable developers to work faster with a lightweight approach. Working in small teams allows individuals to feel more engaged because they have some influence on how things are built. When a lot of people are working in parallel coordination becomes harder. Ideally we need skilled people who have enough experience to work independently without the guide-rails of process.

Yes, I have seen plenty of organisations with large systems being maintained, expanded and extended by multiple teams. When each team has to interface to many others decisions take longer to make. Where a large number of people are working on a complex thing, it takes a lot of effort to keep up with what’s happening other areas and most reduce their focus to the work at hand. Once they reduce their focus and interfaces between teams become walls to hide behind. When myopia is easier then teams tend to make local suboptimal changes rather than considering the whole.

A large body people working on a large body of code often feels crazily chaotic or oppressively bureaucratic to work within. In these conditions developer motivation is often dimmed, people leave taking away valuable knowledge of how the system evolved and why things are. New people who need to learn how things work join and struggle to make sense of it all, the situation gets worse.

There are a few agile practices that can help in scaled up situations - such as having reliable automated builds, decent test coverage and teamwork but these are also painful to maintain with a lot of people involved. I’ve seen many large organisations attempt to apply Agile at scale. It’s hard and although it can bring more humanity to work in-the-small, I’m not sure there is much evidence that it is actually better than traditional ways of organising the work.

I appreciate that there are large systems out in the world that need to be supported and evolved to better meet user and business needs. I remain unconvinced that throwing a lot of people at the problem makes things any faster. I believe deadlines driving this behaviour are defined without realising the impact on the maintainability and quality of existing software. Code is an asset and so is the knowledge that software developers carry - businesses can run into costly mistakes if they ignore their value.

Attempting to scale to go faster is driven business greed and ambition - not a bad thing in the commercial world but it’s like seeing a someone blindfold attempting to run along a cliff edge while juggling priceless antique glass vases. Mistakes at scale are costly!

When it seems that scaling up is the only way to go, challenge yourself to think of a smaller simpler thing to build sooner that gives faster feedback. Try to limit your total Work-In-Progess by reducing the amount of development being done in parallel across the organisation. When a smaller group of people is involved in development, choices about which way to go next can be made more quickly and there's less waiting around. Ultimately, this goes back to Agile Manifesto values - focus on better interactions betweem individuals to produce valuable software sooner -- not on a process to enable lumbering projects at scale.

Categories: Blogs

10 things the Product Owner can do to drive the team crazy

Scrumphony - Marc Löffler - Thu, 01/23/2014 - 11:58

It’ about time to give the Product Owner a chance to fight back. With the help of Heiko Weltin I created a list as a base for the revenge. I hope you’ll like it:

  1. Create your product backlog without any prioritization. In the end you need all of the features before you can bring the product to the market.
  2. Only create the headline of your user stories and don’t add any additional content, even if the team asks. You can’t prepare everything for the team.
  3. Only use two types of priorities: “Urgent” and “Can be done later”. Anything else would be a waste of time.
  4. Always promise release dates and scope to your customer without talking to your development team upfront. You are a skilled estimator.
  5. Always add one task to a user story that keeps the team from finishing it. The Definition Of Ready (DOR) is for wimps.
  6. Insist in long running sprints of at least four weeks. If the team has more time, more features can be done.
  7. Only prepare as many stories as needed to finalize half of the sprint. The rest of the time it is the task of the developers alone to clarify the rest of the stories.
  8. Only meet once a week with the team and keep this meeting as short as possible. You don’t want to hang out with those sissies.
  9. Always answer your phone during any team meeting. Don’t leave the room as the team shouldn’t be able to continue the discussion without you.
  10. Never attend the daily scrum. Instead, talk to single developers afterwards. This makes it easier to build pressure on them.

What do you think? Do you have some additions to this list? Feel free to add them in the comments.

Categories: Blogs

10 things to drive your Product Owner crazy

Scrumphony - Marc Löffler - Thu, 01/16/2014 - 16:44

It’s about time to nag the product owner, isn’t it. Fortunately, there are plenty ways to do this. To help you in your quest to do so I created a list of 10 proofed ways to drive your Product Owner crazy:

  1. Five minutes before the Sprint Review is the right time to tell your Product Owner that your team wasn’t able to finish anything. It is even more fun, if this was a planned release. Transparency is for milquetoasts.
  2. Don’t invite the Product Owner to any Scrum meeting. He is a chicken and you are the pigs, right.
  3. Ignore the Sprint backlog and work on the features you like the most. Who cares about the Product Owner’s vision?
  4. Assign all tasks that were created during your retrospective to your Product Owner. He is the root of all evil and responsible for all the problems in the project.
  5. Don’t attend the Sprint Review. You already know how your product looks like.
  6. Never show the real product in the Sprint Review. Instead, prepare a nice and shiny power point presentation.
  7. Never talk to the Product Owner if you have questions about a feature. Instead, implement it based on your favorite assumptions.
  8. If it is difficult to establish a stable communication to your Product Owner, define someone in your team to become the so called Product Owner proxy.
  9. Always break your release date promises. Everyone loves surprises.
  10. Question everything that is in the product backlog and try to start lengthy discussions about as many features as possible. At least, that’s what your mother told you.

Try this out and post your experiences in the comments. If you have additional ideas, feel free to add them, too.

Categories: Blogs

10 things to wreck your retrospectives

Scrumphony - Marc Löffler - Wed, 01/08/2014 - 16:48

The new year has just started and it’s time for the next steps to rile your team mates. So let’s have a look at one of the activities in Scrum that can be easily sabotaged: the retrospective. Here are 10 proofed ways to wreck any retrospective:

  1. Keep the retrospective as short as possible. No need to invest too much time in this meaningless gathering.
  2. Only focus on negative events and ignore any positive things. This is the only valid path to improvement.
  3. Handle a retrospective as any other meeting. Sit around a table and just talk.
  4. Ignore the complexity of the system around you. There is always a cause and effect.
  5. Always use crappy material such as cheap post-its that easily fall from the walls or old pens that hardly write.
  6. Forgo a facilitator for your retrospectives. It is only a burden and will slow the whole “meeting” down.
  7. Don’t use any agenda and deliberately ignore the retrospective’s phase model.
  8. Directly start with defining what has to be changed in the next sprint. Everybody already knows what has to be done.
  9. Never check if the defined tasks of the last retrospectives were done or even had the desired effect.
  10. Never bring food to your retrospectives. Hungry participants will do anything to finish a retrospective as fast as possible.

What else could you do? I’m looking forward to your suggestions in the comments.

Categories: Blogs

10 more things a Scrum Master can do to drive the team crazy

Scrumphony - Marc Löffler - Thu, 12/19/2013 - 16:04

Aaahhh!Now that the team is armed with new weapons, it is time to help the Scrum Master to fight back. If you didn’t read my first post on this topic have a look at the 10 things a Scrum Master can do to drive the team crazy blog post I wrote two years ago. Here we go:

  1. Get you own office, if possible in a different city or even country. Working at the same location as your team could be harmful.
  2. Count the number of finished tasks per team member and confront those lazy buggers with the obvious low performance.
  3. Try to restrict the communication with the team to Email only. You don’t want to hear their whiny voices.
  4. Don’t tell the team what you are working on. Transparency only applies to the rest of the team.
  5. Always cite the Scrum guide if members don’t stand to the Scrum rules. Continuous repetition will help raising the team’s understanding for this process.
  6. If a team member has a question, point them to Google. Google has all the answers, right?
  7. Ignore the Product Owner. It is his responsibility to create and maintain the backlog, not yours.
  8. Don’t attend the Sprint Review. It is a meeting exclusively between the PO and the team.
  9. Nurture your lack of interest about the product the team is building. This is something the PO has to take care of.
  10. Bring drums to the team’s office and play them like on a slave ship. Every good team needs a beat.

I’m looking forward to your additions in the comments :)

Categories: Blogs

10 more things to drive your Scrum Master crazy

Scrumphony - Marc Löffler - Mon, 12/16/2013 - 11:44

CrazyIt’s been a long time since I wrote “10 things to drive your Scrum Master crazy” and it’s about time to give you some new weapons. So, here they are:

  1. Hide the SM’s beloved moderation markers.
  2. Play on your smartphone during the (planning) meetings, as long as they are not talking about YOUR tasks.
  3. Always lament about the same things but don’t change anything.
  4. Keep blaming and finger pointing everyone else except yourself for all the problems, you are only a victim.
  5. Ignore all agile values as they don’t apply to you.
  6. Simply ignore your Scrum Master, especially when he tries to coach you. Coaching is evil!
  7. Ignore the findings from your latest retrospective because you have more important stuff to do.
  8. Write as many things as possible on ONE post-it. Clustering is much more fun this way.
  9. Don’t put your tasks on the sprint backlog. Your Scrum Master is an evil micro manager. I swear. Transparency sucks.
  10. Ask your boss to put the Scrum values into the performance goals of every employee.
Categories: Blogs

Chief Craftsman at tapped to improve Microsoft’s Visual Studio product line News - Tue, 07/31/2012 - 13:58 announced today that its Chief Craftsman, David Starr, will soon be joining Microsoft as Senior Program Manager in Visual Studio ALM. 

Since joining in 2011, David has driven significant improvements in all of’s programs, and has dedicated himself to helping teams around the world improve their software development. David is leaving his post as Chief Craftsman for to help Microsoft continue improving Visual Studio to support agile software development practices.

In discussing his new role David said, “There is a saying that the tool sets the rules. As unfortunate as that statement is, it is true for many organizations who don’t yet value people over process and process over tools. I look forward to delivering products that encourage good agile practices with a focus on better people interactions and higher quality software. Creating features for a product that is used by millions of software developers is humbling.”

"It is with mixed emotions that we bid David farewell," said Alex Armstrong,'s co-founder and VP of Business Development. "David has made incredible contributions through his work at, and we will miss him at each and every Daily Scrum. As part of the team, David has been directly helping to improve the profession of software development. We are excited that he will be able to continue to do so with a company as central in the software development universe as Microsoft," Armstrong continued.

“I have been privileged to work with the thought leaders at The Professional Scrum Trainers and others in the Scrum community are some of the most committed and talented people contributing to our craft,” said Starr.

“I will miss my interactions, heated discussions, and finally resolutions with David.,” said founder Ken Schwaber. David drives integrity, and that is essential to’s mission and to the well-being of our profession.

Asked about the significance of Microsoft’s choice, Armstrong summarized, ”By bringing a Scrum practitioner with David's unique mix of talents into a leadership role on its flagship ALM product, Microsoft is clearly telegraphing its commitment to supporting Agile and Scrum teams. Agile’s influence in software development has been increasing steadily over the past decade, and this seems to be a clear demonstration of the trend continuing.”

You can read more about David’s future plans on his blog.

Categories: Communities is Hiring - Looking For an Experienced Marketing Manager News - Fri, 07/06/2012 - 16:42 is seeking a talented, driven, and seasoned Marketing Manager to join its Marketing team to help lead its growth.
Categories: Communities

Suspending Scrum Extensions News - Thu, 07/05/2012 - 23:05 is suspending the Scrum extension program, effective immediately.
Categories: Communities

Daily Scrum: Not Just for ScrumMasters

I never refer to the daily scrum (or daily standup) meeting as a “status meeting.” The term “status meeting” is too pejorative for most of us. For me it conjures images of sitting around a table with each person giving an update to a project manager while everyone else feigns interest while either mentally preparing for their own upcoming update or wondering how much longer the meeting will last.

I prefer to think of the daily scrum as a synchronization meeting. Team members are synchronizing their work: Here’s what I did yesterday and what I think I’ll do today. How about you? Done well a daily scrum (daily standup) meeting will feel energizing. People will leave the meeting enthused about the progress they heard others make. This won’t happen every day for every team member, of course, but if team members dread going to the daily scrum, that is usually a sign of trouble.

I want to offer one of my favorite tips for an effective daily scrum: If you’re a ScrumMaster, don’t make eye contact with someone giving an update. Making eye contact is human nature. When we speak, we make eye contact with someone. It’s only natural that a team member will look at the ScrumMaster; call it a legacy of too many years under traditional management but a lot of people on Scrum teams do look at their ScrumMasters a bit like managers to whom they need to report status. By not making eye contact with someone giving an update, the ScrumMaster can, in a subtle way, prevent each report becoming a one-way status report to the ScrumMaster.

Each person’s report is, after all, intended for all other team members.

Categories: Blogs

Check In, Don’t Check Up

I’ve never been a micro-manager, especially not since using agile and Scrum. I could have turned into a micro-manager early in career, except I’ve always been too busy to spend my time checking up on people. But, while I’ve avoiding checking up on teams or people, I’ve never been reluctant to check in with them. I was recently reminded of this by reading an article about the importance of small wins.


While checking up and checking in may seem similar, there are four key things a good ScrumMaster or agile project manager can do to avoid crossing the line into micro-management while still checking in on a team:

1) Be sure the team has the full autonomy to solve whatever problem they’ve been given. A good ScrumMaster ensures the team is given complete autonomy to self-organize and achieve the goal its been given.

2) Don’t just ask team members about their progress; offer them real help. ScrumMasters do this, for example, by protecting the team from outside distractions and removing (or even anticipating) any impediments.

3) Avoid blaming individuals. Things will occasionally go wrong. Assigning blame when that happens will make people feel they are being checked up on rather than just being checked in with.

4) Don’t hoard information. Micromanagers tend to view information as a resource to be retained and only shared when needed. A good ScrumMaster will share anything learned by checking in with others who could benefit from it.

So, stop reading this blog and go check in with your agile team right now. Just don’t check up on them.

Categories: Blogs

GASPing About the Product Backlog

I’ve been wondering lately if Scrum is on the verge of getting a new standard meeting–the Backlog Grooming Meeting, which is a meeting an increasing number of teams are doing each sprint to make sure the product backlog is prepared and ready for the start of the next sprint.

a product backlog

To see why a Backlog Grooming Meeting may be a few years away from becoming a Generally Accepted Scrum Practice, or what I call a GASP, let’s revisit the early 2000s.

Back then, Scrum didn’t have a formal Sprint Retrospective Meeting. Prevailing wisdom at the time was, in fact, fairly opposed to such a meeting. The logic was that a good Scrum team should be always on the look out for opportunities to improve; they should not defer opportunities to discuss improvement to the end of a sprint.

That argument was a very good one. However, what was happening on teams was that day-to-day urgencies took precedence and opportunites to improve often went either unnoticed or unacted upon. And so what most teams eventually realized was that of course we should improve any time we notice an opportunity, but at a minimum each team should set aside a dedicated time each sprint for doing so–and thus the retrospective became a standard part of Scrum. This was helped along tremendous by the great book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen.

I’ve had more CSM course attendees recently asking questions about a Backlog Grooming Meeting as though it were a GASP. Many are surprised when I tell them that not every Scrum team has such a meeting each sprint. I still don’t advocate every team conduct a Backlog Grooming Meeting each sprint–as with the early arguments against retrospectives, I’d prefer backlog grooming to happen in a more continuous, as-needed way–but so many teams are successfully using a Backlog Grooming Meeting, arguments against it may be on their last gasps.

Share what you think below. Will a Product Backlog Grooming meeting become so common it becomes a Generally Accepted Scrum Practice (GASP)?

Categories: Blogs

Interview on National Public Radio about Daily Standups

Following the article in the Wall Street Journal on daily standup meetings a few weeks ago, a number of other places have interviewed me abut the topic. I don’t know why they’re asking me, but the interviews have been fun so far. The latest was on the National Public Radio (NPR) Marketplace show on Monday, 20 February 2012. You can listen to the whole show but Sarah Gardner’s interview with me begins at 18:50.

Categories: Blogs

Points Are About Relative Effort Not Ranking

I’m thinking of buying a new car. So I’ve put together a list of cars to consider. Here they are in priority order:

  • Bugatti Veyron Super Sports
  • Pagani Zonda Clinque Roadster
  • Lamborghini Reventon
  • McLaren F1
  • Koenigsegg CCX
  • Porsche Carrera GT
  • Aston Martin Vanquish
  • Toyota Prius
  • Toyota Camry
  • Tata Nano

Unfortunately, though, I’m not sure I can afford my top priority car. So let me put some points on each car. I’ll start with the least desirable car and put a 1 on it, a 2 on the next car, etc. That reorders our list so with points on each car we get:

  1. Tata Nano
  2. Toyota Camry
  3. Toyota Prius
  4. Aston Martin Vanquish
  5. Porsche Carrera GT
  6. Koenigsegg CCX
  7. McLaren F1
  8. Lamborghini Reventon
  9. Pagani Zonda Clinque Roadster
  10. Bugatti Veyron Super Sports

Now I think about my personal spending limits and I can spend between $25-$50k on a car. I’d like to be closer to $25k but a good salesman might get $40-50k out of me. Since the Tata Nano (at one point) goes for about $2500 that means I can afford between 10-20 points.

So, looking at the list again and the points assigned to each car, I think I’m going to buy a Bugatti (10 points), a Pagani (9) and a Tata (1 point). Unfortunately, when I show up at the Bugatti dealer, I am somewhat informed that the Veyron lists for $2,400,000.

What went wrong here?

The problem is that points are not a ranking. When we rank product backlog (or car backlog) items we use ordinal numbers (such as first, second, third). We cannot add ordinal numbers together. We cannot say that the distance between first and second is the same as from second to third. The Bugatti in this example is not ten times the cost of the Tata.

Ranking stories (or cars) like this is worthless. We want story points to instead reflect the relative effort involved. For cars we could put points on as follows:

Tato Nano 1 Toyota Camry 12 Toyota Prius 14 Aston Martin Vanquish 102 Porsche Carrera GT 193 Koenigsegg CCX 218 McLaren F1 388 Lamborghini Reventon 640 Pagani Zonda Clinque Roadster 740 Bugatti Veyron Super Sports 960

These points are of course based on the relative costs of these cars. I need to be able to do the math on these estimates that someone would want to do. Someone can afford 20 points on a car–which should they buy? Should I buy this item for 10 points or those other two for 5 points each? You can’t do that when points are assigned via a ranking.

Story points on an agile product backlog represent the effort to implement the backlog item. Since cost on most software projects is made up almost exclusively of labor (rather than buying parts), we can think of a story point estimate on the product backlog as being the cost, as in the car example here.

And, when I look at the relative costs here, I can tell I belong in the Toyota dealership rather than the Bugatti dealership.

Categories: Blogs

Psst...Scrumy has an API now

Scrumy Blog - Thu, 07/01/2010 - 07:00

It's a new month, and now there is a new Scrumy feature for Pro users: The Scrumy API. Pretty much anyone who has asked us if we have an API recently has already been directed to that page and has been able to access it, but now we're sharing our secrets with the world.

For the uninitiated, an API is an interface that we give to you in order to access the data that we've stored for you in a convenient way. Essentially, it allows you to write your own programs that interact with your Scrumy projects. If, for example, you wanted a big red button that moves all your unfinished tasks into the 'Done' column, you could build that yourself with a few clever API calls.

The Scrumy API is divided into two separate parts: REST and Webhooks.

The REST API allows you to get data from your projects in XML or JSON form using simple URLs. You can also manipulate your data by POSTing or PUTing data to those URLs. You can read all about it at the REST API documentation page.

Webhooks are very different. A Webhook is a URL for an application that you have running on your own server which receives data from us. This means that any time you create or change a task, for example, we will send a piece of data representing the change on your project to that URL. A simple thing you could do with this would be to send a tweet any time you finish a task. Read more at the Webhooks documentation page. Also, the demo is set up to use webhooks, but it works a bit differently than your projects. The demo will allow you to enter 5 webhooks, but none of them will be active for more than 5 minutes. So, if you just want to see how webhooks work, feel free to use the demo, but unless you want to be a jerk, use an empty slot. Then you have 5 minutes to test your heart out.

So those are the big updates for now. If you find errors while reading the apidocs or feel that you could clarify something, feel free to update the documentation. It's a wiki for a reason. If you have any other questions or comments, feel free to contact us at

Categories: Companies

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.