1. 10 Tips for a Great Daily Scrum Meeting by Platinum Edge – The daily Scrum meeting is a powerful tool that keeps your project moving. At the same time, it is also easy for the meetings to not bring any added value.

2. Tips for Effective Backlog Grooming  by Charles Bradley – Are you wasting time in your Sprint Planning Meetings? Increase the value of your team’s Sprint Planning Meetings by grooming your Product Backlog.

3. Yoda’s top 10 tips for a new Scrum Master by Nigel Steane – As a new Scrum Master, you face unfamiliar challenges and your success is very much based on your ability to utilise coaching and soft skills to gently guide your team and colleagues.

4. Top ten tips for distributed Scrum team teleconferences By Jon Archer –  After acting as a Scrum Master for several months on a distributed team with people in six different locations, three different countries, learn ten tips to help get past those inevitable awkward silences.

5. 10 tips for adopting Scrum to save your project by Matthew Hodgson – Are you interested in adopting Scrum for your next project? Here are 10 tips from his experience with moving a number of projects from their existing project management frameworks to Scrum.

6. Five Tips for Impediment Resolution with Scrum by Stefan Roock – Impediments can slow down or even halt the progress of an otherwise well-functioning Scrum team. Take a look at the most common challenges that crop up on teams and what steps you can take to resolve them.

7. 10 Tips for Succeeding with Enterprise Agile Development by Tools Journal – Many enterprises are experimenting with agile development approaches like Scrum, Kanban, Lean, and XP hoping that introducing a new development approach will help. Yet, agile development has struggled to achieve critical mass in large enterprises.

8. 6 Tips for Good Scrum by Martin Harris – If you are doing these 6 tips, then you are doing very well and are likely to get better over time.

9. 9 Tips for Creating a Good Sprint Backlog by Luciano Felix – Giving attention to the sprint backlog creation process is fundamental to the team’s understanding of what should be done and how to better plan during the sprint.

10. 7 Tips for a More Effective Daily Scrum by Richard Lawrence – The main purpose of the Daily Scrum is for team members to make and follow-up on commitments to one another that work towards the team’s shared sprint commitment. Here are seven ways to get your Daily Scrum back on focus If your it has become unfocused, too long, or otherwise ineffective.

If you have any other good articles related to agile, please share them in the comments. Thanks.

We are hosting a free live agile webinar (Agile and Scrum Q&A Webinar) on March 28, 2013 at 11:00 AM PDT that is going to consist of questions sent in from the agile community. The content of what we talk about is entirely up to you.

We need your help to make this webinar informative and awesome. Please submit an interesting question or problem you are currently facing in your organization that you would like covered during the webinar. If there is time at the end, we will answer follow up questions.

If your question or problem is used during the webinar, we will send you a $25 amazon gift card. Please send your questions to team@axosoft.com.

Register at: http://www.ontimenow.com/training/scrum-webinar

If you can’t make it on that day, register anyways and we will send you the video recording of the full webinar.

For those of you that don’t know, Pure Chat is a simple, yet powerful free chatting widget that allows your website visitors to instantly chat with your sales and/or support team.  I won’t go over the features in this tutorial, but you can learn more information by checking out the tour.

Important: When you update WordPress, the changes you make with this tutorial shouldn’t be affected. However, if you decide to change or update your theme, it will overwrite footer.php and you will have to add the Pure Chat javascript code again. Luckily, after the first time, it should only take you a few minutes to do.

I created a test blog for this tutorial. It uses the default WordPress template. However, this tutorial should work with any template.

Step 1: Log into your WordPress Admin dashboard. The default login url is /wp-login.php. Once you are logged in, you should see something similar to the image below.

Step 2: Hover over “Appearance” in the left-hand menu. This will open up a sub-menu. Click “Editor.” Note: If you don’t see the “Editor” option, you most likely are using WordPress.com (or another hosting provider), and they currently restrict access to “Editor” feature.

Step 3: You should now be in your theme editor. As you can see below, I am editing the default WordPress theme, Twenty Twelve’ Stylesheet (style.css). The content in the box and in the right menu labeled “Templates” will be different depending on what theme you are using. However, this doesn’t change what you are going to do. On the right hand menu, you will be looking for the template section named “Footer (footer.php)”. In the image below, it is highlighted by the red box. Click “Footer”.

Step 4: Now, you can see that I am editing the Twenty Twelve: Footer (footer.php). Your footer content will be different, depending on the theme that you are using. However, you will still be looking for the “</body>” tag. In the image below, you will see a red arrow next to the </body> tag. Go to Step 5.

TIP: No matter what theme you are using, the closing </body> tag will be at the end of all content. Therefore, if your theme has a lot of content in the footer, you might have to scroll to find the </body> tag. If you have to scroll, I suggest scrolling as far down as possible and start looking for the </body> tag from the bottom up. You can also use the browser searching capabilities.

Step 5: Ok, now that you have found the closing </body> tag in the previous step, you need to register for Pure Chat if you haven’t done so already. You can see in the image below that is is extremely easy to register. Not to mention…Pure Chat is FREE and includes an unlimited operators and chat sessions, all with no hidden costs!

Step 6: After you register, the first thing you will see is the javascript that you need to use in the next step. So, copy the code and go to the next step.

Step 7: You located the closing </body> code in Step 4. Now paste the javascript code you copied in the last step right BEFORE the closing </body> tag. In the image below, the highlighted content is the javascript code for my Pure Chat widget. You can see that the code is BEFORE the closing </body> tag. To save your changes, press the “Update File” button.

Step 8: You have now installed Pure Chat on your WordPress website. Below is an example of an active chat with myself.

Pure Chat makes it extremely easy to add live chat for WordPress websites. You can add and update your chat widgets right in the Pure Chat dashboard. I hope that this simple tutorial helps you add Pure Chat to your WordPress blog. Please let me know if you have any questions and I will gladly answer them.

If you’re anything like me, you’ve been wanting one of the new, almost-MacBook-Air-thin iMacs since the moment you laid your wide eyes on one. Someday, I’ll justify the purchase. The good news for you is that no one ever has to justify winning something.

The bad news for me is that I’m not eligible for this contest. Heck, we’re also giving away two iPad 3s and seven Nexus 7s — that’s 10 prizes in all that will be going out to the 10 best apps submitted in our upcoming API contest. If you’re a smart developer, you’ve probably already beaten me to calculating the odds on winning here…I mean how many apps could be submitted in a contest like this anyway?

Oh, the contest. It might help if I back up and explain a bit.

OnTime RESTful APIs & Developer Website

Recently, with OnTime 13, we launched new RESTful APIs along with a new OnTime Developer Website. This is the beginning phase of a new ecosystem we envision for supporting developers who would like to extend the functionality of OnTime, as well as integrate it with other applications.

The developer website gets you started, provides full documentation, and shows you how to obtain a Vendor API Key (in case you would like to develop apps and integration abilities not limited to your OnTime instance). Check out the site »

The Contest

We’ve kept the contest nice and simple:

• Get Started at http://developer.ontimenow.com to learn about the APIs and obtain your API key;
• You can create as many apps or integrations as you would like;
• Submit your apps by March 29, 2013;
• Winners will be announced on April 12, 2013
• Odds of winning will be 10 / (number of apps submitted)
• Your personal contact for the event and for partnership opportunities is Sean Gately.
• Full details are available here

What App Should I Make?

The contest is open to any app that utilizes the OnTime RESTful APIs. This can include an integration with a 3rd-party application (like CRM systems, time keeping solutions, accounting software, etc.). Or, you can create a new tool that is designed specifically for OnTime users to help them better manage their backlogs, attachments or any other aspect of the system.

Whatever you decide to develop with OnTime’s APIs, be sure to submit it to us before the deadline, and don’t hesitate to contact your contest liason, Sean Gately, if you have any questions or comments. Sure the prizes are awesome, and the odds of winning are probably going to be super sweet — but the big benefit here is in extending OnTime or helping it to play nice with your other favorite apps.

We look forward to your submissions!

The status page is located at http://www.ontimenow.com/support/status.

At which data center is my instance of OnTime located? Good question. We plan on including this information inside of OnTime in a not-too-distant release. In the meantime, be sure to bookmark the status page, check it if you are having any issues, and it’s generally safe to assume that your data center is located in geographical place that is closest to you.

OnTime OnDemand Status Web Page

We had the opportunity to chat about OnTime with a ton of awesome attendees and we are really excited about the positive feedback we received about our latest release, OnTime 13. Also, it was awesome to meet the faces behind some of the thousands of companies that are already using OnTime — thanks for stopping by the booth and I hope that you enjoyed the swag!  

Axosoft is dedicated to sponsoring software related events that help the development community. We sponsor and attend events throughout the year, so keep a look out for us and definitely come say hello!

Check out some pictures from the event:

The Axosoft booth loaded up with swag!

A few of the Treasure Chest “Key to Agile” Promotion

Nexus 7 Winner (1 of 2)

Tego Audio Speaker Winner (1 of 10)

Axosoft T-shirt Winner (1 of 30)

Dud keys — hey, they can’t all win!

We’re preparing our 2013 conference schedule, so if you have a conference that you thing would be good for us to sponsor drop us a line at ‘team — at — axosoft — dotcom.’

New Card View (Kanban/Scrum Board)

My most favorite feature is the new “Card View” that replaces our Visual Planning Board. It looks like this:

The new Card View is an order of magnitude more powerful than the Visual Planning Board that it replaces. Cards are more compact allowing more cards to fit on the screen. Group headers now provide much more detailed information about the status of the cards in a given group. You can also filter the cards by project, release or assignee using the standard organization panel on the left. Drag-and-drop to reassign cards to different releases, projects, sprints and team members. If you expand the details section, you can even see the details of the currently selected card including description, attachments, work logs and more. The new Card View works exactly like the super powerful grid view did and that’s what makes it a lot more powerful than before.

With OnTime 13 we are also introducing a new Stack Ranking feature where you can drag-and-drop items to re-order how they appear. Since you can sort view items by any field in OnTime, stack ranking in OnTime is essentially another sort order. You can view your list by Stack Rank sort order and of course, you can drop into “Ranking Mode” to re-arrange the stack. It looks like this:

Once an item is stack ranked, the ranking of the item is maintained regardless of what group of items are viewed within OnTime. So you can stack rank the entire V5.0 release or just Sprint 3. Either way, the items that get ranked maintain their rank as you move up or down the release tree. When viewing items sorted by stack rank mode, you can also group them by other fields such as Assignee so that you can see all the items assigned to a particular person stack ranked appropriately.

A lot of you have been asking about release-based security and filtering releases based on what projects a user has access to. We can’t believe we lived this long without this feature. Now that we’ve been using it internally, we can’t live without it.

Here’s how Release-Based Security/Filtering works. For each of your Projects, you can assign which Products from your releases tree are associated with the project. This is done from a new tab in the Edit Project screen:

Once you’ve said which products/releases belong to a particular project, OnTime will do the rest. Each time you select a project, only the appropriate releases that are associated with that project are shown. If a user doesn’t have access to a particular project, then they can’t see the releases associated with that project branch. It’s super simple and works extremely well. It’s nice to have your releases tree filtered down to just the releases from the project you are looking at.

Lots of Other Stuff

There’s lots of other stuff too. Like the update to the Security UI, new REST APIs (documented at developer.ontimenow.com) and better help options inside the product. So check it out and let us know what you think.

You can also watch a video of the new features here:

When we launched the product in August, we launched it with 1 operator free and $7/month for additional operators. While this is the lowest price we could find for such a sweet tool, we decided we want to go after a the largest possible market share, so we’ve made it 100% Free for Unlimited Operators!

So go ahead, get Pure Chat and add a Free Live Chat solution to your web site right now.

“What does not kill me, makes me stronger.”
Friedrich Nietzsche, German philosopher (1844 – 1900)

Let’s face it: we all spend a lot of time doing the same things. Even in dynamic roles where “everything is always changing,” we often find ourselves trying to solve the same kinds of problems, while working in the same kinds of environments. Although this is immensely practical, and to some degree necessary, it can possibly hold your team back insofar as strengthening and enhancing important skills.

hor • mes • is noun
the phenomenon in which low doses of toxins produce stimulating effects.

Hormesis is a theory, by which it is believed that exposure to a little bit of something that is bad for you, can actually be good for you — i.e. a little stress is a good thing.

Exercise is a great example of a stressor. Not only do people who exercise get better at the act of performing the exercise itself, but benefits are often seen in other areas, such as a reduction in depression and anxiety disorders. Hormesis is also the fundamental theory behind other health strategies: calorie restriction, cold therapy, heat therapy, even radiation therapy.

As professionals, can we can benefit from this concept, too? If we can change things up a bit, throw in a little randomization from time to time, maybe we can fire up parts of our brains that we normally don’t get a chance to trigger. These little sparks can lead to improved professional health and growth in ways that we otherwise cannot easily achieve.

For example, how about throwing yourself into a situation where you have to do this:

This is exactly what we did at Axosoft in the month of July. Our development, QA, and marketing teams all stepped away from our familiar, if not cozy, work areas and projects. Our month-long hormetic ice bath was an exercise in creating new things from scratch, tight schedules, bootstrappy work conditions, and a lot of unknowns.

As a participant, I can say without pause, that we came away from this experience stronger. We created Dashzen and Pure Chat, but perhaps more importantly, we learned to work with each other in new ways, we all picked up new skills, and we were able to get a good glimpse at what we are capable of doing.

In the end, we were all glad to return our focus to Axosoft’s core products, ready to apply what we had learned and to face our day-to-day challenges with sharpened instincts. In fact, the next version of OnTime will immediately reap some of the benefits of what we learned in July — more on that to come soon.

So is a little hormesis in order for your team? If not a month-long stressor, perhaps building some randomization into your normal routine? Be sure to watch Two New Startups in 30 Days — Dashzen & Pure Chat and let us know what you think.

The way I see it, there’s two major problems:

The observer effect: The observer effect states that observing a process can impact its output. For instance, telling a team that you’ll be keeping a close eye on their velocity might cause that team to overestimate their items in order to increase their velocity. This is especially dangerous when working with story points since there’s no way to compare the validity of an estimate. Should your Scrum team stop using story points?

The streetlight effect: The streetlight effect is our human tendency to look for answers where it’s easy to look rather than where the actual information is. For instance, counting the lines of code produced is easy but doesn’t tell us anything about the quality of the application, the functionality it provides or even the effectiveness.

So let’s apply these concepts to some common Metrics. What’s easy to measure?

Unit Tests written: Most agile developers write a lot of unit tests, test driven development creates even more tests(both of which create better quality code). So measuring a developer’s productivity by the number of tests they create must be good!

Actually, the observer effect kills this one dead. Telling a developer that they’ll be measured on the number of tests they write ensures they’ll create many tests with no respect to the quality of those tests. Our goal is not to ship tests, our goal is to ship working code, I’ll take fewer better tests than more crappy tests any day.

Individual Velocity: Once again the observer effect makes this a bad metric. If a developer knows he’s being individually graded on his performance and also knows that he only gets credit for the things he specifically works on then he’s actively discouraged from contributing to the group. He’s placed in the very un-agile situation of competing with his team rather than contributing to it.

In a perfect world an Agile team is collaborating, interacting, discussing and reviewing almost everything they do. This is a good thing for building quality software and solving problems fast but this level of interaction makes it nigh impossible to separate a person’s individual productivity from the group, so don’t try, you’ll simply hurt your team’s ability to make good software.

Team Velocity: This is one of the most misunderstood metrics in all of Scrum. A team’s velocity is unique to them. It simply can’t be compared to another team. Let’s say that team A estimates a certain amount of work at 50 pts for a sprint and team B estimates that same work at 150 pts for the same sprint. Now if both teams finish their sprint successfully then team A has a velocity of 50 pts and team B has a velocity of 150 pts. Which team is more productive? Neither. They both did the same amount of work.

This metric is particularly evil because it encourages teams to fudge the numbers on their estimates which can affect the team’s ability to plan their next sprint. If the team can’t properly plan a sprint then that puts your entire release in danger of shipping late.

For more about your Scrum team’s velocity, you can check out an earlier blog post I wrote.

Okay smart guy, what metrics should we use?

Glad you asked, we measure productivity by the working software we deliver. We measure actual output rather than contributing factors. This approach is more Agile because it frees the team to build software in whatever way can better contribute to their success rather than whatever way creates better metric scores. It’s also much more logical since working software is something that we can literally take to the bank (after it’s been sold of course).

So what are the actual new metrics?

Value Delivered: You’ll need your product owner for this. Ask him to give each user story a value that represents its impact to his stakeholders. You can enumerate this with an actual dollar amount or some arbitrary number of some kind. At the end of each sprint you’ll have a number that can tell you how much value you’ve delivered to your customers through the eyes of the product owner.

This metric does not measure performance, instead it measures impact. Ideally your product owner will prioritize higher value items towards the top of the backlog and thus each sprint will deliver the maximum value possible. If you’re working on a finite project with a definite end in sight, your sprints will start out very high value and gradually trend towards delivering less and less value as you get deeper into the backlog. At some point, the cost of development will eclipse the potential value of running another sprint, that’s typically a good time for the team to switch to a new product.

On Time Delivery: People sometimes tell me that Agile adoption failed at their company because they couldn’t give definite delivery dates to their clients. I don’t buy this. One thing that an Agile team should definitely be able to do is deliver software by a certain date. It’s possible that a few stories may not be implemented but those are typically the lowest value stories that would have the least amount of impact on the client. That being said, a team’s velocity should be reasonably steady, if it goes up or down it should do so gradually. Wild swings in velocity from sprint to sprint make long term planning harder to do.

Here’s the metric: if a team forecasts 5 stories for an upcoming sprint and they deliver 5 stories then they earn 2 points toward this metric. If they deliver 4 stories or they deliver less than 2 days early (pick your own number here) then they earn one point. If they deliver more than 2 days early or they only deliver 3 (out of 5) stories they earn no points. At the end of a quarter or the end of a release or the end of the year the team will be judged by how accurately they can forecast their sprints.

So what we’re measuring is value delivered to the customer and on time delivery of that software. Which are the only two real metrics you can literally cash checks with.