Posts Tagged ‘agile’

Scrum Overview Diagram

February 27, 2012 6 comments

It is challenging to find a good, high-level summary of Scrum that you can share with your team.  One that visually describes the core concepts of the methodology in a way that anybody can understand. After having produced the new Scrum in 10 Minutes video, we decided to take a stab at this using the visuals from the video. What do you think?

Download the Scrum Overview Diagram PDF

We are releasing this Scrum Overview Diagram under the Creative Commons 3.0 license so you can share it or put it on your own blog.

Categories: Development, Team, Tools Tags: , ,

New Scrum in Under 10 Minutes Video

February 23, 2012 1 comment

Shane the Videographer

Late last year, I felt it was about time to update the now 3-year old “Scrum in Under 10 Minutes” video. The video has been immensely popular having been viewed over 600,000 times. In that time I have received a tremendous amount of great feedback for improvements to the video. I had a few ideas of my own too, so I wanted to see if we could redo the video and still keep it under 10 minutes.

For nearly a year I’ve also had the pleasure of working with Shane, Axosoft’s resident videographer. Shane is an amazing artist and he helped make the new scrum video visually unbelievable. We’ve been working on the new version of the video for nearly 3 months (actually mostly Shane has been working on it and I just keep bugging him), and it’s finally ready for its debut.

Here it is:

Intro to Scrum Video

Axosoft at the Agile 2011 Conference

August 22, 2011 1 comment

Earlier this month we spent a few days in Utah at the Agile 2011 conference as “Gold Sponsors” of the event. It was a very fun show. We met a lot of great people and gave demos of the new user experience of OnTime 11. We also gave away quite a bit of swag, including these popular Tego Audio Portable Speakers.

Here is a quick video compilation of the highlights:

Watch Axosoft’s Agile Conference Video on YouTube

Scrum Planning Board on the iPad

February 1, 2010 13 comments

We thought it would be fun to imagine what the OnTime V10 Scrum Planning Board (a.k.a. task board) would look like when used through the iPad:

The touch interface of being able to drag-and-drop cards from one workflow step to another is going to absolutely rock on the iPad. I need to get my hands on one of these things asap! :-)

Project Management with Scrum

August 28, 2008 10 comments

Scrum burn-down chartSuccessful project management is easy. Successfully executed projects have at least these 3 common elements:

  1. Somebody (or everybody) maintains a list of everything that needs to get done, broken down into manageable chunks, with time estimates for completing each chunk;
  2. Every team member has a prioritized list of those chunks, which they are responsible for completing;
  3. There’s at least one person who monitors the progress to make sure things are on track.

Perform the above 3 tasks, and your project will have the highest probability of success. Sounds simple and it really is that simple! Even if you did the above 3 tasks on paper, without the use of any fancy tools, your chances of succeeding would be greatly enhanced. Project management is not rocket science, but rocket scientists performed the above 3 tasks to land a man on the moon in 1969 with less collective computing power than the iPhone strapped to my belt.

Over time, however, best practices for how exactly to perform the above 3 tasks have emerged into hundreds (if not thousands) of project management books. Numerous methodologies have emerged, many from NASA. Most of these process-driven methodologies detail exactly how teams should perform every nitty-gritty task. Yet, with all these awesome project management methods and years and years of experience, NASA, perhaps the icon of organized project management, cancels and/or delivers more late and over-budget projects than it did back in the 60s.

Why is that? Why is it that NASA, with all of its project management wisdom, couldn’t dream of doing what a few engineers did with the leadership of Burt Rutan — building a spaceship for under $30 million and winning the X-Prize? Rutan and his team built a rocket that can carry 3 people into space and an airplane that carries the rocket to launch to a high launch altitude.  And, they successfully launched it into space twice in two weeks.

The world is full of examples where “regular” amateurs with far fewer resources and a lot less project management structure end up beating out larger, well-established companies that have relatively unlmited budget and their process methodology down to a science.

What all of these amateurs have in common is that none of them use a heavyweight, well established process to manage their projects. There are no examples I know of where a new company or team used a six-sigma process to unseat a leader in the field, but there are plenty of examples of a couple of 20-year old kids who worked using the “fly by the seat of your pants” method on a computer, search engine, operating system, web site or some other gadget that ended up changing the world.

Corporate America is also taking note. Some companies have recognized that the biggest risk to their well-established business is the “fly by the seat of your pants” methodology and they’ve decided to embrace it, although most are doing so reluctantly, without enough urgency, and half-heartedly.

Adoption of agile software development techniques, such as Scrum, are rapidly growing as a result of the flexibility they provide in managing projects the way a team sees fit.  Google is a great example of a company who has whole-heartedly embraced the fly by the seat of your pants, entrepreneurial techniques. They have built their success as a company who employs little process, manages through chaos and has little structure in anything they do. The result is a company that is nimble, quick and surprises the industry and competitors with both its hits and misses.

Axosoft’s own customer base, as illustrated by a recent survey, is also of the belief that rigid project management techniques don’t pay. More than 60% of Axosoft customers don’t use any particular software development methodology.  But, of those who do, Scrum, a relatively new agile development technique, is the one that’s gaining the most popularity. That’s no accident.

A Quick Look at Scrum

Scrum’s popularity is rooted in its back-to-basics philosophy; its simplicity and flexibility in execution. If you are new to Scrum, you might want to start with this presentation that Ken Schwaber (co-founder of Scurm) delivered for Google:

Ken Schwaber Introducing Scrum at Google

When I watched this video, one thing that stuck with me was the fact that Google engineers were getting introduced to and encouraged to use Scrum. If Google, a company that thrives on chaos, is embracing Scrum to some level, then it’s worth investigating more. So I set out to learn as much as I could about Scrum.

There are a number of great resources on the web. The Wikipedia page on Scrum is a good starting place. After reading a ton of material on the subject, I started to truly appreciate Scrum’s simplicity.

Scrum can be summarized as follows:

  1. Projects have a list of things that need to be accomplished. Since these items are not yet done, we’ll call this list the “Product Backlog“. It contains everything we’d like to have in the product.
  2. To keep things manageable, we’ll select a handful of items from the product backlog, assign them to team members and focus on getting just those items to a ship-ready state. We’ll call this the “Sprint.” We’ll keep sprints relatively short so that in a particular product release, we have at least several sprints. The shorter our product release cycle, the shorter the sprint duration.
  3. To keep track of where things are, we’ll add up all the estimated hours of work currently remaining and compare the total to previous days to make sure it is consistently going down at a rate that is in line with our expectations and will meet our goals. We’ll call this the “Burn Down.” Charting the burn down information is an effective way to visualize the progress.

With just the above 3 concepts, any team can successfully implement Scrum. To make sure I had the basic concepts down, I picked up the phone and had a conversation with Ken Schwaber (co-founder of Scrum, founder of Control Chaos and author of a few books on the subject). Ken and I hit it off right from the start. Scrum is about common sense. It doesn’t define a rigid process, but rather a flexible one. It focuses on project visibility while everything else is about the basics (making a list, prioritizing and checking them off one-by-one).

Flexibility is the key to success with Scrum. Some teams, especially those who come from a high-process background expect Scrum to have definitive bounds for everything, to explicitly define every detail. A sprint is exactly 30 days (it’s not!). A must-have stand-up meeting that’s precisely 4 minutes 30 seconds long. You get the idea. But Scrum is about allowing teams to define the ideal practices for their situation based on team size, project size, release cycles, etc. A 2-man team working in the same room on a new web product might have weekly release cycles and no need for meetings, while a 100-person team working on a 10-year old, mature accounting package will have vastly different needs. Scrum’s flexibility is what allows it to work for both teams.

To be sure, Ken Schwaber and Jeff Sutherland (the other co-founder of Scrum) have done a lot of work to define Scrum in far more detail. They define common terminology for roles, best practices for conducting meetings and other project management events that are generally required for a successful project. But the basic concepts, much like the basic concepts of boolean algebra, are simple.

Scrum and OnTime

If you are an OnTime user, you’re probably wondering how OnTime handles the needs of Scrum teams. Looking at the above 3 fundamentals of Scrum, OnTime manages them in the following ways:

  • Product Backlogs – The default OnTime “Features” tab is an ideal place to store product backlog items. In fact, many OnTime customers who use Scrum rename the “Features” tab to “Product Backlog” or “User Stories” in order to use the Scrum terminology. You can do that from the Tools -> System Options menu.
  • Sprints – The ideal way to manage sprints in current versions of OnTime is by creating a custom field called “Sprint”. The field could be a picklist populated with potential sprints. You can then assign items to these sprints.  And, since OnTime’s main list of items can be filtered, sorted or grouped by  sprint at this point, you can easily look at the items for a given sprint.
  • Burn Down – Current remaining workload for a given sprint, release, project, or any other filtered list can be obtained by simply looking at the status bar in OnTime’s main window. However, OnTime falls short in providing historic burn down information in the form of a burn down chart.

Here are some screenshots of OnTime being used in a Scrum environment:

OnTime Used in a Scrum Environment

In the above screenshot (click to enlarge), the following areas are highlighted:

  1. As you can see, the “Features” tab has been renamed to Product Backlog (this is done from Tools menu -> System Options -> Item Types). To illustrate a focus on Product Backlog, I’ve also removed all other tabs from the view.
  2. I’ve renamed “Feature” (the singular reference to the item type) to “User Story” which is more inline with the terminology used in Scrum. So in scrum, you add a new “user story” to your product backlog.
  3. I’ve grouped my view by Sprint. In this case, I’m looking at all the sprints for the currently selected project and I’ve created a custom picklist with my sprint names.
  4. In the taskbar area, you can see the highlighted section identifies the current workload for the items in our current view. Since our view can be filtered to a project, a sprint or by a user, you can quickly see the workload by a number of different criteria and you can see how much work remains.

It’s also worth illustrating how easy it is to assign a bunch of items to a particular sprint:

Assigning Groups of Items to a Sprint in OnTime

In the above screenshot, you can see how a group of items are being assigned to a particular sprint using the multi-edit menu. In the above screenshot, the view is grouped by the custom Picklist field I’ve created called Sprint and since items not assigned to a sprint are shown in the “[None]” group, it’s easy to quickly identify those items in our product backlog and assign them to a sprint.

Future of Scrum in OnTime

OnTime is an extremely effective tool for managing Scrum projects, but I think we can do a far better job in future versions of OnTime. To make sure we fully embrace Scrum for future releases of OnTime, I had our entire team learn about Scrum. I also made sure we had multiple team members attend a two-day workshop with Ken Schwaber to become certified “Scrum Masters.”

Axosoft has embraced Scrum in a big way and we have made Scrum one of the main focuses of the next major release of OnTime. More generally, OnTime 2009’s focus will be on Project Visibility, which will help every single OnTime customer, not just those using Scrum. But for Scrum teams in particular, especially those hungry for some burn down charts and other visualization tools, you won’t be disappointed.

I can’t wait to talk more about the upcoming features, but that’s for another blog and another time.

Building a Great Team

November 12, 2007 6 comments

A Good Team is Critical to Success of a ProjectThe centerpiece of any successful development project is the team that builds it. There is no other single most important contributing factor to building great products. No tools, no development methods, no amount of money and no amount of time can substitute for the importance of an exceptional team if you plan to create an exceptional product.

Some in our industry operate under the assumption “with a good system and a fine-tuned set of processes, you can build anything with a group of average Joes.” If that sounds like your company, congratulations! You must be that average Joe. The assumption that with the right systems and tools, anybody could build great products couldn’t be any further from the truth.

Only driven, motivated and talented teams can make great products. Heavy systematic methodologies of product development and processes can only slow down those teams to ensure that the slowest person on the team can keep up. Process-heavy systems are designed for the weakest team member and therefore must slow down the pace of all other team members to ensure that few mistakes are made by those who are not exceptionally skilled. The cost of such systems is incredibly high.

See if this sounds familiar: Your team is fast at work on the latest project. Due to the size and importance of the project to the company’s success, the executive team is providing the budget necessary to expand the team. It’s estimated that your team will need to increase the “headcount” by 5 or 10, in order to meet its project deadlines. To quickly ramp up for the new required headcount, the bar for qualified candidates falls nearly as fast as the team’s cohesiveness. Within a short time your team successfully adds 10 new “heads” to meet the aggressive project schedule.

To ramp up the new members as quickly as possible, they have been given the proper one-day overview of the project. They weren’t even asked to write code until Day Two. Soon these new team members start contributing thousands of lines of code. Productivity seems at an all-time high. Tasks are getting done in record time and the team now seems to be functioning on all cylinders. If you’re lucky, within a couple of weeks, the first set of problems start to reveal their ugly heads. All kinds of new nasty bugs show up in QA (assuming, of course, that there is a QA team). Senior team members have to take time off of their tasks to track down these nasty issues. After days of searching and going through weeks of code line-by-line, some suspected line code are identified. The first question asked is “who wrote this crap?” and so the process expands.

In order to find out who’s responsible for poorly written code in the future, “checkin” rules requiring detailed comments are put into place.  Additionally, every single line of code is now required to go through a complete and formal code-review to help reduce errors.

The team’s pace changes drastically. Things slow down and soon it’s obvious that the deadline targets of the project schedule are impossible to meet. At current pace, you easily need to increase the headcount by another 5 to 10 to make the ship dates.  But, even that is unlikely as a frustrated, but competent teammember finally speaks up and reminds the executives (and everybody else in the room) that 9 women can’t make a baby in 1 month.

Finally, everybody comes to accept the missed deadlines and the pushed back release dates. Life goes on…slowly.

There is a Better Way

There is, of course, a better way. Among engineers and project managers, it’s common knowledge that a really good engineer can be 3, 5 or even as much as 10 times more productive than a bad engineer. What a load of crap. You’re probably thinking I’m nuts. You might even be thinking that you personally know software engineers who are 3 or 5 times more productive than the guy in the next cube. What you don’t realize is that you are probably discounting their productivity.

It’s possible for a good engineer to be infinitely more productive than the engineer sitting next to them. How is that possible? Consider this: in 1975, how many engineers could have single-handedly done what Steve Wozniak did in designing the Apple I and later the Apple II? What about the search algorithms used by Larry and Sergey (Google)? I know that if you had given me 10 years, it’s not likely that I would have thought of page ranking or search in the way that Larry and Sergey did. So how much more productive were they? I’d say about ($)150 billion times!

The problem with comparing people in terms of multiples of productivity (such as person X is 5 times more productive than person Y) is that there is an underlying assumption that both person X and person Y can do the same job. That is a huge and usually wrong assumption. Two people might be able to do the same job and if one of them is generally 5 times more productive than the other, that probably means there is a whole realm of things that is possible for one of them that’s impossible for the other.

With that in mind, if you were working on a hardware project and estimated that you needed 10 more engineers to get the job done, would you take 10 “Average Joes” or would you settle for 1 Steve Wozniak? If you were working on a Search-related project, would you take 10 “Average Joes” or 1 Larry Page or Sergey Brin? If the answers to those questions seem obvious to you, so should the importance of building a great team. It’s not about “headcounts.” It’s about talent. So to create a winning team, keep a few simple rules in mind:

  1. Hire the most talented people you can possibly find. Don’t hire someone if they don’t meet the bar you’ve set. I know it’s extremely tempting to lower the bar when it’s hard to find good people. Remember that a bad hire could actually have negative productivity!
  2. Create a system that’s flexible and light in process. Implementing any kind of canned methodology that has steps outlined from A to Z on how to create products and manage teams ensures that your team will operate at a low efficiency. A more dynamic and light-weight, low-process system is ideal when your team is already talented enough to know how to do the right things.
  3. Eliminate team members that consistently fall below the bar. Don’t kill them. Just fire them or move them to a different position if you can. If you can’t get rid of team members due to corporate culture or red tape, give them tasks that are non-critical to the success of your project. Often times you can increase productivity faster by removing team members than you can by adding them. If you find that you’re adding process to your efficient system because of 1 or 2 people who consistently need detailed guidelines to get work done, those are the guys I’m talking about.
  4. Create a culture that appreciates talent. Talented people like to work with other talented people. That’s how they’re satisfied. By giving them freedom to do the right thing and taking obstacles (and dumb people) out of their way, you’re creating a culture that appreciates and rewards talent.

By putting the emphasis on the team rather than the process, you’ll create much better products at the end.

Why Software Methodologies Don’t Save Software Projects

November 9, 2007 7 comments

Rigid Systems Can’t Save Software ProjectsAccording to Wikipedia, in Software Engineering, a Methodology is defined as:

A codified set of practices (sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools) that may be repeatably carried out to produce software.

Unfortunately, that definition is believed by many, and it’s dead wrong. If you believe it, your projects may be doomed to failure.

Methodologies are systems for the creation of things. A system designed to manufacture cars at Ford or hamburgers at McDonalds is a methodology (although not a software methodology). Ford manufacturing plants produce new cars through an assembly line where each phase of construction is extremely well defined. It’s defined to the point that even robots participate in various phases of construction. You can interchange people who work in the assembly line with relative ease and almost no impact on the end result. There’s quality assurance at every phase to ensure that each benchmark is within the predefined limits. All of this results in the manufacturing of nearly identical cars, in every single instance. It works great.

Likewise, McDonalds has a similar strategy for making hamburgers. The steps to create a burger are well defined. If you change the cook, the burger will still be the same with the same amount of materials, same ingredients, same cooking temperatures, same sauces and the same wrapping. McDonald’s burger-creation methodology results in the customer enjoying the same burger, every single time. Their success is proof that the system works and it works well.

Methodologies Don’t Produce Software

So why not a system for the creation of software? If Ford can do it for cars and McDonalds can do it for hamburgers, why can’t we have a system to produce software? The answer is that we can. The catch, however, is that the system can only re-create software that has already been created. The system cannot produce new software just as Ford’s methodology for creating new cars will never create a different kind of car. It’s designed to re-create the exact same gas-guzzling, poor quality, tire-exploding and boring car in the exact same way that you have come to expect from Ford. So it is at McDonald’s. The system doesn’t create a new kind of hamburger. It simply re-creates the same bad-tasting, low-quality, high-calorie hamburger that you’ve now come to expect from McDonald’s.

In the same light, a software methodology cannot produce new software. This concept is a major surprise to a lot of companies and the US Government, who after spending hundreds of millions of dollars on software projects that end up being canceled — projects that should have been fool-proof in their success. After all, they used the most concrete software methodologies known to man-kind (or to Grady Booch). How could such software projects fail?

Learning that methodologies or well-defined systems and processes can’t create things is important. People create things. Systems and methodologies can only re-create things, but only after people create them first. So what about successful software projects that have employed rigid systems and software methodologies? Easy. Such projects have succeeded in spite of the methodologies used, not because of them and it’s virtually guaranteed that a less restricted team would have accomplished the same task in less time.

New Trends in Software Development

The world is slowly coming to the realization that people are the most important part of any successful new software project. No systems or processes can substitute for your top software engineers. Take your own software projects as an example. Would you give up the top one or two team members or would you give up your software methodology? My guess is that the answer is a no-brainer. Even in a team of 100, losing the top couple of team members would be far more detrimental to the success of the project.

You have undoubtedly heard of new software methodologies such as Agile and Scrum. The popularity of these new light-weight systems is exactly because of the reasons I have explained above. They put the emphasis on people. Is it any surprise that trimming down detailed, process-heavy, software methodologies has produced much better results? Of course not. These new systems are putting the emphasis on individual team members, finally coming to the acceptance that the individuals are far more important in the creation of new software. The systems should only support the individuals, not get in their way. Unfortunately, even these new methodologies are slowly becoming heavy. Scrum is becoming better defined by the day and the more it gets defined, the more Scrum Masters who insist on having a burn-down chart from day 1 on a new project, the more such projects will suffer.

Finding the Right Balance

Like everything in life, there is a balance that each team must obtain between systems and processes and team and individual freedom. Each project is different. There is no one system that can meet the needs of all teams and no single implementation of a system that should be used instead of another. Google’s founders didn’t start with a methodology. Neither did YouTube or FaceBook. Even well established companies like Microsoft and Apple didn’t (and still don’t) have rigid systems in place and they provide significant team freedom to choose the right amount of process for their projects.

So unless you have a lot of free tax-money to waste or if you work on human-safety systems, reconsider the weight of your software methodology. In software, lighter is usually better.

%d bloggers like this: