Agile 101

Project Management, Digital Publishing and Agile Software Development

Archive for the ‘Featured’ Category

Scrum on Demand – Getting Started with Scrum

Posted by Tara Hamilton-Whitaker on October 12, 2009

I feel honoured to share an article written by Hamid Shojaee, CEO of Axosoft. Hamid is the creator of the most viewed Scrum video on the web – Scrum in 10 Minutes and is, quite frankly, rather clued up!

Here, he shares a few of his pearls of wisdom…

Enjoy!

By: Hamid Shojaee

So you are sold on Scrum, but having a hard time getting started, right? There are a lot of questions on your mind:

  • How do I convince the team to use Scrum?
  • How long should our sprints be?
  • How should we handle bugs?
  • What if our estimates are not accurate?
  • How do we handle items with dependencies across sprints?
  • What tool should we use to track everything?
  • How do I get my team trained on Scrum?

We’ll tackle each of these questions in this article.

How do I convince my team to use Scrum?

Remember that “using Scrum” mostly means the following things:

  1. Making a list of things that you need to get done for the project (product backlog)
  2. Prioritizing that list
  3. Estimating how long each item in the list will take
  4. Meeting regularly to see the status of items and make small adjustments
  5. Keep track of how much work remains until the project is finished (burndown chart)

So if you are getting any push-back from your team, management or executives on using Scrum, then don’t refer to it as Scrum. Come in with a plan that says you want to do the 5 things listed above. The resistance will immediately dissipate because there will no longer be a fear of the unknown. It’s hard to argue that “making a list of things we need to get done” is a bad thing. You’ll know it as the product backlog, but who cares if others call it that?

How long should our sprints be?

As a general rule of thumb, most dev teams have a typical “release cycle”. My standard recommendation is that make sure you fit at least 4 sprints to as many as 12 sprints into your release cycles.

So if your typical release cycle is once every 6 months, it wouldn’t be a bad idea to have 6 sprints of 30-days each. On the other hand, if your release cycle is only 3 months, you still might want 6 sprints, but make them 2 weeks each.

How should we handle bugs?

There are two types of bugs. There are those that:

  1. Appear while you’re still working on a given feature PRIOR to the completion of the feature and
  2. Bugs that are identified AFTER a feature is considered feature-complete.

Bugs that are identified PRIOR to the feature being completed should be dealt with right away and the feature should never see the light of day without the bugs being addressed. However, the challenging part of bugs is how to deal with the bugs that are identified AFTER the feature is completed and released in the product.

There are two main schools of thought here. Neither is better than the other. Use the one that fits your team best. Here they are:

  1. Log bugs just like any other product backlog item and in each sprint, take a handful of bugs to address in each sprint. In this scenario, bugs and features are thrown into the same product backlog and prioritized, estimated and dealt with just like any other product backlog item.
  2. The other school of thought is to track bugs in a separate “Defects Backlog” and have dedicated sprints that focus on nothing but bugs to help everyone stay focused on creating the most stable product. The idea here is that with everyone in the team focused on fixed bugs, nobody is busy introducing new bugs by coding new features and as a result, the team will produce a more polished product.

How do we create more accurate estimates?

The first thing to remember is that nobody creates accurate estimates. The key is to create an accurate overall target release date that is manageable. So there are some best practice rules on creating better estimates.

Here they are:

  1. Involve at least 2-3 of your most experience engineers on creating estimates, along with the person who will ultimately be responsible for coding it. Take the higher estimate value if the group doesn’t agree.
  2. Keep estimates at approximate values that are thrown into larger buckets. For example, your “estimate values” might be:
    • 1 Hour
    • 2 Hours
    • 4 Hours
    • 8 Hours
    • 2 Days
    • 3 Days
    • 5 Days
    • 2 Weeks
    • 3 Weeks
  3. If an item is estimated to take 10 minutes, that falls into the 1-hour bucket. If it’s estimated to take 3 or 4 hours, that probably falls into the 8 hour bucket. Being conservative with estimates will address some of the unavoidable down-time for estimations.
  4. Expect no more than 6 hours of productivity each day from each software engineer. That means the typical software engineer should plow through 30 hours of estimated work per week. Don’t expect more because they have overhead of meetings, checking email and Facebook!
  5. Lastly, be sure to leave room in your overall schedule for unforeseen items, changes that will inevitably be made and other things that you simply can not predict. Generally speaking, you’ll want about 1 week of padding for each month of development. So on a 4 month project, don’t take on more than 3 months worth of work.

How do we handle items with dependencies across sprints?

Dependent and complex items are essentially the high-risk items in software development projects.

To minimize the risk, there are two things you can do:

  1. Use Proof-of-Concept prototypes as often as possible. These throw-away projects should help demonstrate the feasibility of high-risk items. These items include anything that the team does not have experience developing, which might include a new cool User Interface design, back end data storage, cool new web interface and so on.
  2. Tackle the tough tasks in your first few sprints. This will help you identify problems early. You don’t want to find out two weeks prior to your ship-date that a task that was expected to take a couple of weeks will in fact take a couple of months. Putting high-risk items first, will help you get project visibility early that will allow you to change things up to address your timeline.

(Read more about minimising the impact of Sprint Disruptions on Agile101)

What Scrum tool should we use to track everything?

It’s always surprising when I find software development teams that still use Excel or even sticky notes, paper and white boards to manage the development of a software project. After all, we are all in the business of creating software that makes some manual tasks easier. There are dozens of software applications out there that are far superior to using Excel or an offline solution.

One example of such a tool (my favorite, in fact :-)), is my company’s product, Axosoft OnTime.

OnTime is designed to stay out of the way of software developers so they can focus on writing code, which is what software developers do best. But it also provides project managers, scrum masters and executives with all of the project visibility tools that are instrumental in helping them make decisions about the direction of the project.

Here is how OnTime helps Scrum teams:

The Product Backlog

OnTime allows for Scrum teams to manage their product backlog in either of two ways:ss_scrum_backlog

  • Single Backlog for Everything – The ability to see everything that relates to a given product, version or sprint in a single product backlog is a nice way to view project information. It allows teams to deal with bugs in the same way they deal with any other requirements.
  • Separate Backlogs for Defects (Bugs) and Features (Requirements) – OnTime also allows teams to separate defects, features and tasks into independent backlogs. This level of flexibility allows for each type of item to have a separate workflow, allowing defects to go through a different process than feature requests. For example, a defect might need to be verified, while a feature requests first needs approval.

Regardless of which way you decide to go with the product backlog, OnTime provides powerful backlog features that are useful for every user, including:

  • Ability to create public and private backlog filters with powerful AND/OR functionality for combining conditions
  • Ability to group backlog items to view them by assignee, status, workflow step or any other built-in or custom field
  • Ability to create saved public or private views which save everything from fields being displayed, the sizes of each column, filter conditions and more
  • Ability to set first, second and even third sort criteria so that you can view your backlog in the way that makes most sense
  • Ability to apply a change (such as status, workflow, date or other changes) to multiple items with the click of just 1 button

These features make OnTime one of the most powerful tools on the market for Scrum teams who need fine controls on their product backlog management.

Sprint Planning

ss_sprint_planningSprint planning is one of the most important activities that Scrum-based teams perform. With OnTime, sprint planning takes form naturally from the product backlog. Assigning items to a sprint is as easy as dragging and dropping (in the OnTime Windows client) any number of items from your product backlog onto a planned sprint. Alternatively, you can use the multi-edit feature to assign a number of product backlog items to any given sprint.

To create the planned sprints, OnTime also makes the Scrum Master’s job easy. The OnTime Releases hierarchy breaks projects in the following way:

  • Products – You can manage any number of products in OnTime
  • Versions – Each Product can have any number of versions
  • Sprints – Each Version has numerous Sprints

OnTime also provide auto-calculators for sprint start and end dates. You simply tell the system how many days your typical sprint is and OnTime will automatically calculate the dates.

Daily Standups

All meetings are overhead. With that in mind, the goal of meetings should be to keep them as short as possible (and as Einstein might say, “but no shorter!”). OnTime facilitates meetings, such as the Scrum Daily Standup, by having all the information that’s needed to make decisions ready at hand. A typical meeting starts in a conference room with the main OnTime screen being projected on a screen with a “Daily Standup” Previously Saved View applied to the system to show only the items of focus for the given sprint.

The team has the ability to go through the items right there, make notes, change status and so on, allowing the meeting’s decisions to be captured in real-time without further work that would typically be assigned to the Scrum Master.

Tracking Progress (Burndown Charts)

ss_scrum_burndownIf you don’t track it, there is no way to improve it. Furthermore, project visibility is perhaps the most important factor for project success. That’s where Scrum burn-down charts play a pivotal role to making sure projects are on track and OnTime provides an extensive set of capabilities when it comes to Project Visibility and Burn-down charts, including:

  • View a mini burndown chart on the main OnTime page, giving everybody on the team the same sense of urgency to move the project in the right direction
  • Multiple burndown charts depicting one or more sprints, versions or products in a fully customizable Charts Dashboard
  • View rollups of burndown charts for multiple sprints for a given version of a product
  • Show trend (such as the burndown velocity) and project a ship-date for a given version or completion date of a sprint

The OnTime dashboard provides a number of other useful charts too, like the Treemap, or Trend Reports and even user workloads to make sure you are not overloading a particular team member with too much work.

It’s Scrum On-Demand

OTNow_saas01With Axosoft’s OnTime Now! Scrum teams can actually signup for and start using a 30-day, 10-user trial of the OnTime system in seconds! Axosoft has done an incredible amount of work to make the OnTime Now! system exceptionally unique with the following features:

  • Choice of 6 Data Centers world-wide for maximum Hosted performance
  • Ability to use either a web client or the rich OnTime Windows client (this is unheard of in a hosted solution)
  • Ability to use OnTime Visual Studio or Eclipse plugins for developers so they never leave the IDE
  • Ability to use OnTime iPhone client, a full-featured app that provides dashboards, access to all items and much more – incredibly useful for every team member, especially the Scrum Master

The best part of the OnTime Now! hosted solution is that there is no compromise and there are no contracts. You get to use both Web, Windows, iPhone, Visual Studio and Eclipse OnTime clients and the entire thing is hosted in any of 6 different secure data centers that Axosoft manages around the globe.

Learn More About OnTime Now! >>

It’s Inside of Your IDE (Visual Studio & Eclipse)

eclipse_plugin_win_mac_linuxDesigned to stay out of the way, OnTime provides the ability for developers to stay in the environment where they are most productive: The development IDE. OnTime supports both Visual Studio and Eclipse and allows developers to access the information they need right at their fingertips. The Visual Studio and Eclipse plugins allow users to:

  • Add, Edit and modify the workflow or status of items directly in the Eclipse and VS IDEs
  • Filter, sort and view items in a variety of ways
  • Add notes, attachments and work log entries for items
  • View items associated to a product, version or sprint

For developers, nothing is more productive than being able to stay in the IDE while modifying project management related tasks

It’s Even in Your iPhone

iphone_main_medData was meant to be shared and viewed from everywhere. That’s why OnTime provides every team member with the ability to access their OnTime system from the convenience of their iPhone. The OnTime iPhone client provides some powerful features, including:

  • View and edit all item types (defects, features, tasks and incidents)
  • Filter and sort the product backlog(s)
  • View items by project, product, version or sprint
  • Add attachments, notes and comments to items
  • Log work done on a given item
  • View a number of built-in charts or create custom charts meeting any filter criteria

The OnTime iPhone client is intuitive and powerful.

How do I get my team trained on Scrum tools?

The last piece of the puzzle is how do you get your team trained on the tool that you select? Axosoft has a solution for that too. In fact, Axosoft offers a number of FREE Web-Based, Instructor-Lead classes on the following subjects:

  • Implementing Agile / Scrum Methods with OnTime (Class code OT-302) – This hour-long class walks you through how to setup an OnTime database to use Agile or Scrum terminology, setup product backlogs and get going with burndown charts.
  • OnTime End-User Essentials (Class Code OT-101) – This hour-long class walks typical users through the main OnTime interface covering the day-to-day operations of users, such as creating and applying filters and views, creating new items, comments, attachments and more.
  • OnTime Administrative Essentials (Class Code OT-102) – This hour-long class walks your OnTime administrator through the setup process, new user creation, customization of fields and field templates and other administrative tasks.

Did I mention these web classes are free? But they are only available on a first-come-first served basis as class attendance is limited to ensure each person has an opportunity to ask questions.

Book a FREE Web-Based, Instructor-Lead Class Now!

//

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

Advertisements

Posted in Agile Estimation, Featured, Reviews, Risks and Issues, Scrum Backlogs | Tagged: , , , , , , | 1 Comment »

The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!)

Posted by Tara Hamilton-Whitaker on September 8, 2009

Here’s a VERY simple overview of the main differences between Waterfall DevelopmentIterative Waterfall Development, Scrum/Agile Development and Lean.

Waterfall Development

‘Waterfall Development’ is another name for the more traditional approach to software development.

It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).

In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!

This approach is highly risky, often more costly and generally less efficient than more Agile approaches.

The main issues with this approach include:

  • You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development)
  • You leave the testing until the end, which means you’re leaving issue discovery until late in the day
  • You don’t seek approval from the stakeholders until late in the day – their requirements might have changed
  • You’re heavily reliant upon a plan, which you can/will often follow to the detriment of the end result
  • You’re heavily reliant upon a project manager driving the way – the power of one

Iterative Waterfall Development

This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches.

The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features.

The most commonly occurring issue in this type of scenario (in my experience) is bottle necking.

For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing.

Another common symptom of this type of approach is over-commitment.  It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way. 

You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined.

For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases.

It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development

This approach carries far less risk than Waterfall approaches.

We focus on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature.

With that said, we still plan our work in iterations and we will still release at the end of each iteration.

Lean Development

Lean is very similar to Scrum in the sense that we focus on features as opposed to groups of features – however Lean takes this one step further again.

In Lean Development, you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature. By doing this, you further isolate risk to a feature-level.

In these environments, you aim to eliminate ‘waste’ wherever possible – you therefore do nothing until you know it’s necessary or relevant.

//

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

the-difference-between-waterfall-iterative-waterfall-scrum-and-lean

Posted in Featured, Project Management | Tagged: , , , | 16 Comments »

What does 'Done' mean in Agile Software Development?

Posted by Tara Hamilton-Whitaker on September 4, 2009

what-does-done-mean-for-an-agile-software-development-team

In Agile Software Development environments, we aim to deliver ‘[potentially] shippable code’ at the end of each iteration.

In actual fact, we often settle for delivering a chunk of value at the end of each iteration.  This ‘value’ may or may not be directly attached to a piece of shippable code. 

We also aim to close each iteration with no leftovers, no dependencies – everything must be ‘done’.

I recently watched a Google Tech Talk by Jeff Sutherland where he discusses ‘Done’ (Scrum Tuning: Lessons Learned at Google). 

Jeff explained that ‘Done’ at Patient Keeper, his company, is a piece of code live to the public having received no complaints within an hour of release.  

This got me thinking.

  • So, what is ‘Done’?… 
  • Does ‘Done’ HAVE to be ‘live with no complaints within an hour of release’?…
  • Does ‘Done’ HAVE to be potentially shippable code?
  • What does ‘potentially shippable’ mean?
  • Does ‘Done’ HAVE to relate to the delivery of code?
  • Can ‘Done’ change one a case by case basis? …

In traditional, Waterfall, environments, we follow a series of consecutive steps running between project inception and completion – we understand that we are ‘done’ when all of the steps are complete, the product is released, we disassemble the project team etc.  This is a relatively simple concept to get your head around.

In an Agile environment, however,  we follow these steps each iteration… in fact, we probably follow these steps a number of times per day.

Of course we’re interested in being ‘done’ with the project, but we’re more interested in being ‘done’ with each task, each story and ultimately each deliverable that will in turn deliver value.

So, now we need to define ‘value’! Is value *only* delivered by shipped code? Probably not.

For example, the objective of a Spike is to get a clear idea on where to go next.  ‘Done’ in this situation might be a working prototype that might end up being released – if you’re lucky.

On the other hand, the task(s) could be to deliver a series of findings that inform a decision – ‘Done’ might be a firm decision one way or another e.g. completion of the Planning and Analysis stages.. (see inset image)

As mentioned above, you may decide not to release at the end of each iteration. You may schedule releases around Minimum Marketable Features or Epics that span multiple sprints. In these cases ‘Done’ may relate to the delivery of ‘potentially shippable’ code, which has been fully-tested, acceptance tested and performance optimised (as much as possible).

So, it becomes clear that the definition of ‘Done’ may indeed neeed to vary on a case by case basis.

With that said, regardless of what your definition of ‘Done’ is, the definition must be understood by everyone involved.

//

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

Posted in Featured, Project Management | Tagged: , , | 3 Comments »