Scrum’s no silver bullet. It’s the holster!

Ken Schwaber and Jeff Sutherland, the creators of Scrum, describe it as a lightweight framework designed to address complex problems in an adaptive manner, while creatively delivering products of the highest value. I like to say Scrum is common sense. They say that it is simple to understand, but extremely difficult to master. I say the “extremely difficult to master part” could point to a team or organization’s lack of common sense or their willingness to acknowledge weaknesses.

You’ve heard too often that Scrum is no magic bullet. Folks says that for the same reason they say Scrum is difficult to master. Scrum is a process framework designed to manage complex product development, but it can’t do the work for you. Think of this framework as a tool, better yet, a bicycle. Climb on a bicycle. You can ride across country, but the bicycle isn’t motorized. You still have to apply muscle to get you where you need to go. Climb on the bike backwards, and you’ll find it “extremely difficult to master”, but peddle properly, and you’ll find yourself moving forward.

The Scrumbuts out there would take the chain off the bicycle and tell everyone Scrum didn’t work for them.

Scrum works by exposing the deficiencies of your management and development practices so that you can improve. It is not a silver bullet because it is not a process or a technique for building products. Scrum is the holster for those bullets, a framework of rules and processes to manage the other tools and techniques you employ. Within this holster, you’ll organize your Scrum Teams and their associated roles, events, and components.
Each tool within your holster serves a specific purpose and is essential to your success with Scrum. If you discard one of these tools, you have Scrumbut. However, your holster is large and accommodating. You can add all of the additional bullets or tools you need. Used properly, your holster binds each together by monitoring and managing the relationships and interactions between them.

Put your Bugs where your Mouth is

Last month, Decade Software released EnvisionConnect 4.0—and what a proud day it was.

The new version is the previous version on steroids, and were constantly making strides to improve performance and make the product easier before version 4.1—always focusing on making the application faster for users to get in and out and still feel good about having got the job done.

My Development Team prides itself in maintaining a zero defect average. Every 30 days—during Sprint planning—we commit to closing every open defect in addition to delivering any new features we committed to providing.

Speaking to software shops across the nation, I have not found one who has been able to come anywhere near our zero defect average. (If you know of any, please let me know. I would love to glorify them in this blog!)

I recapped all of the above so that you understand my dismay at hearing someone say this week…

“One of our clients says he doesn’t like the Page Layout Editor”—Yes, we do allow users to redesign forms and pages—”because the user says the tool is buggy.”

Immediately, I searched the defect tracking system and consulted my Quality Assurance team. I wanted to find out how many bugs constituted “buggy” and why we had not eradicated those bugs.

I found no bugs related to the feature in question, aside from a couple we had fixed but not yet released.

Then I knew our problems lay somewhere else.

Is the problem related to the definition: What is a defect?

Not likely. At Decade Software, We have the most lax description in the industry: If the client is “bugged” by something, that’s logged as a defect. Ultimately, we may fix it as a defect in code, or by adding a new feature, or by changing a design, or by providing training for the user—but no defect is ever ignored with the words…

“…that’s just the way it is.”

So, if the code is not the problem, and the definition is not the problem, then there’s only one thing it can be. Someone found a defect and did not report it.

Even the best software teams cannot fix bugs no one has found. It is the responsibility of user—internally and externally—to report any problem found.

Software shops can’t make you happy, unless they know what is making you sad.

Building a better Vulcan

Outside of the office, I love nostalgia, but inside, I am the first to promote change. Keep the things that work. Build on those things, and throw out the bad.

However, when Paramount Pictures took this approach with Star Trek, I was afraid of the change. I did not trust that JJ Abrams would be able to handle the job.

This was because I was not Paramount’s Product Owner, and their team did not ask me for buy-in, when they gathered requirements to fix something that I didn’t think was broken.

I was wrong. The movie was great, and I learned a lesson I have been preaching to others for years…

“The needs of the many outweigh the needs of the few.

–Mr. Spock, Wrath of Khan”

This became clear today, as I was reading new words of wisdom this week from Joel “on software” Spolsky…

“Typically, the product owner wants something simple and easy to understand for the users, featuring a telepathic user interface and a 30" screen that nonetheless fits in your pocket, while the developer wants something that is trivial to implement in code.

Lacking a product owner, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense if you’re a Vulcan. The best programmers are notoriously brilliant, and …have a tendency to get attached to their first ideas, especially when they’ve already written the code.

One of the best things a program manager can add to the software design process is a second opinion as to how things should be designed…

….ideas for how the UI should work, which might be better, or worse, than the developer’s idea. And then there’s a long debate.”

For those of you that speak Scrum, I have substituted Joel’s use of the label “Program Manager” for “Product Owner” to point out that our objectives are the same—the common techniques that work from one software process to the next are essentially the same. Common sense is universal.

Software Engineers know the “how” better than anyone, but the “what” must be defined by those that interact with the customer—or better, by the customer themselves. However, we can’t forget that ancient Decade proverb “everyone doesn’t know what they don’t know”. That’s where the give-and-take and “happy mediums” of good design come from.

Despite what you were taught, compromise is not a bad thing.

In fact, its what makes good teams great. Meeting in the middle has nothing to do with losing ground. It is about everyone coming together to see the big picture and finding the optimal solution for all involved.

Code long and prosper.

Everyone is Authoritative on a self-managed team

One of my teammates said the other day…

“It is important that someone authoritative review all requirements documents.”

I gave him one of my you-killed-my-dog looks.

Considering this definition of authoritative…

“Having due authority; having the sanction or weight of authority: an authoritative opinion.”

…or this one…

“Having an air of authority; accustomed to exercising authority; positive; peremptory; dictatorial.”

…then everyone on a self-managed team is authoritative. This is because they are empowered to track down any answers they do not have.

However, there is another definition of authoritative that may be relevant…

“Substantiated or supported by documentary evidence and accepted by most authorities in a field.”

The most successful self-managed teams are those that are cross-functional, providing them with a balanced view of problems from all sides. If they do not have the variety of inputs they require to answer the questions at hand, they must seek out the advice of the experts—quite often “the experts” translates to “the customer”.

Once the team has collected all available inputs, they weigh the pros and cons—the “whats”—and then the team formulates their best “hows”.

If a better solution comes along later, they don’t waste time and resources defending lesser solutions. They adapt to the better solution ASAP and learn from the experience.

Now, if members of the team aren’t asking the right questions or identifying the domain experts they must consult, then those are different problems—”impediments” in Scrum—and they must be addressed by the team. If those problems are not being addressed by the team or the leaders within the team, only then should they be addressed by a manager.

If you have a process where one person has to “sign-off” instead of a process that compiles the wisdom of the crowds—aka project stakeholders—then you do not have a self-managed team. You have a command-and-control operation, and you are on the slow road to success.

Does your team have have forest goals or tree goals?

This week, Jeff Sutherland revisits the roots of Scrum and expands on why trust is so important to teamwork.

He said…

“With trust based on real unity and cohesion, Boyd's Observe, Orient, Decide, Act feedback loop goes into an implicit state where there is Observe, Orient, and Decisions becomes implicit. The team goes into motion before the leader can give a command. Like in martial arts the Sensei is moving before he even sees the motion of the attacker using a sixth sense. This is the kind of trust a Dream Team has. You know it when you see it, but few software teams have that level of trust.”

I have seen my teams in this state, but they don’t always stay there. 

Such a state is only driven by a “sense of urgency”—a sense is created only when…

1. Clear goals exist—not just “tree goals”, but “forest goals”. Your team must see how the little tasks they’ve committed to delivering add to the “big picture”.
2. The leaders are practicing what they are preaching. Truth, Trust, and Transparency have to be seen more-often than heard.

In that environment, the type of synergy Jeff describes is a no-brainer.

Incidentally, I have a meeting tomorrow to further to try and solidify my company’s “forest goals”. Wish me luck!

Another Team Parable: Quality and the Self-motivated team

Nearly a month ago, I called the team together to discuss defects. I wanted their feedback on an idea that I had.

I started the sentence with “What if…”

Someone said “uh-oh” and some eyes began to roll.

I said, “What if we stopped committing to and addressing all defects during a single 30-day sprint and instead committed to addressing them only in overtime. That way, we’d continue to maintain our zero defect count, but we’d be able to deliver more features, sooner.”

“What do you think?”

My team has always hated overtime with a passion.

As always, they thought I was crazy and told me so…

“This is not Agile,” they said. “This will not work. We’ll be coding into the late hours of night. We’ll be exhausted. Quality will decline.”

The sky is falling. That’s what they said.

I then said what I always say in times of change. “It’s your decision. You are a self-managed team, but I would appreciate it if you would at least give the idea a try. If it doesn’t work, say the word, and we can go back to the old way or try something new.”

And with that, my team elected to trust me enough to give the idea a try.

As I said, that was nearly a month ago.

Yesterday, the Scrum Master who most opposed the overtime idea was in my office for our monthly one-on-one.

He said…

“I’ve noticed something really odd lately. We seem to be creating very few defects lately. Now, even the guys who want to work overtime are having trouble finding something to fix.

“We’re coding the way we always have. We didn’t change our processes at all. We code as fast as we always have, and we test the same way we always have. I just don’t understand what changed.”

I said…

“That is bizarre. It’s almost as if the team found some reason to be more attentive to their work. Perhaps, it’s a testament to your leadership?”

He looked at me a moment and said only, “Isn’t it time for your next meeting?”

Meanwhile, in a country called Scrum...

In the country of Scrum, there is a backlog of bills to be addressed, and there is an impediment list of problems to be solved.

These lists are ordered by the Product Owner—and the Vice Product Owner if the Product Owner is assassinated.

The country of Scrum has two teams. Each team has a Scrum Master, who coordinates meetings to ensure that everyone does what is best for the team and the country.The Product Owner is available to answer any questions and provide any support the teams require.

The Product Owner(s) never interfere with the daily workings of the teams.

The goals of individual team members are rarely considered.

After both teams have delivered on their commitments, they come together, adapting and improving their processes, ultimately delivering a country that all stakeholders are proud of—and one that other country's envy.

I once lived in the country of Scrum, but during some quiet coo, I believe that my country was overthrown by the kingdom of Greed.

Axosoft OnTime adopts Scrum in a big way!

I have made much noise over the past year related to Axosoft OnTime's advertised support for Scrum and the product's shortcomings in this area. I have also explained how Decade Software has found ways to work around those shortcomings—but soon you will not have to.

Hamid Shojaee made this announcement today...

"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."

To be clear, I love OnTime. It has increased transparency throughout our company. My goal all along was merely to hold Axosoft accountable for their advertising promises and help them make OnTime even better.

It looks like that has happened.

Thank you, Axosoft. I am overjoyed at the news, and I am standing by to beta test if you need me.

3 Steps to Better Presentations

Tomorrow, I will be speaking to the Fresno County Office of Education on the subject of Scrum and Teamwork in general, reviewing the accomplishments Decade Software has made over the last few years.

This afternoon, I will be meeting with those who will present classes at the Decade Software User Training Conference next month.

...so I found Peter Stev's thoughts today quite timely.

"How will I know if the audience is getting what they need? Why didn’t I think of this sooner? The answer is simple: identify the users, figure out what they want to accomplish and why. Give the audience what they need to accomplish their most important goals. If you can identify and address their needs even before they are even aware of them, magic happens."

Check out his full post, and let me know what you think.

21 tips for delivering killer presentations

As you know, I worked in radio for 15 years, and I've been speaking publicly since Jimmy Carter was president.

In fact, this month I will be speaking to developers at the Fresno County Office of Education on Scrum.

At the office this week, everyone's getting excited about our user conference, and most are beginning to prepare their training sessions. To assist, I've put together my top 21 tips for public presentations.

1. Know your 15-word summary. Can you summarize your presentation in fifteen words? If not, rewrite it and try again. Speaking is an inefficient medium for communicating information, so know what the important fifteen words are and repeat them often.
2. Develop rapport with the audience. Presentations should be entertaining and informative. The audience expects some appeal to their emotions. Reciting dry facts without passion or humor bores your audience, as does repetitious or unnecessary words. Keep the audience engaged. Interesting talks fly by. Boring ones last forever.
3. Tell stories. If your presentation is lengthy, explain your points using short stories or anecdotes. Great speakers know how to paint mental pictures for the audience, creating emotional connections between ideas.
4. Tell the truth. If someone asks you a question and you do not know the answer, tell them so, but offer to help them find the answers after the presentation, and when you are wrong, say you are wrong.
5. Hold questions until the end. To keep the presentation moving, ask the audience to hold questions until the end. If they have questions not specific to the presentation, ask them to meet with you after the session.
6. Repeat questions. When accepting questions, have the person asking state their name and where they are from. Repeat these details and the question for your audience.
7. Prepare and adapt. Speak to your audience, listen to questions, respond to reactions—adjust and adapt. In case your material is not getting across, be prepared to change strategy. Know what you can (and cannot) omit, and brace yourself for the unexpected.
8. Distribute handouts. Ensure that the audience focuses on your presentation, instead of taking notes. Distribute most prior to the arrival of the audience, and hold additional handouts for late arrivals.
9. Make eye contact with everyone in the room. Sincere eye contact makes everyone in your audience feel involved. Exchange eye contact with many people in the audience for 3 seconds each, and routinely glance at the crowd while speaking.
10. Remember the slide rules. Show no more than 10 slides per 20 minutes with each slide containing no font smaller than 30-point. Using any audio or visual aids, “going large” avoids interruption by making everything easily understandable from the back of the room. Highlight main points within the first few slides, and throughout the presentation, use more words than those on the slides. Also, remember to number your slides (or script pages) in case you lose your place.
11. Never read slides or notes verbatim. Use words as reminders, and spend most of your time making eye contact. Knowing your material makes you more competent and confident—and assures your audience that you are an expert on your subject.
12. Speak with conviction and enthusiasm. With a little practice, you can inject your passion for a subject into your presentations, and enthusiasm is contagious. Structure presentations using logical progressions from introduction (Thesis statement) to body (strong supporting arguments, accurate and up-to-date information) to conclusion (re-state thesis, summary, and logical conclusion).
13. Breathe. Feeling the urge to use presentation killers like ‘um,’ ‘ah,’ or ‘you know’? Replace those with a pause, taking a short breath—in—not out. Allow everyone time to reflect and think. Racing through will leave everyone out of breath.
14. Slow down. Nervous speakers tend to talk fast. Consciously slow your speech down and add pauses for emphasis. Use statements like, “that’s a good question,” or “I’m glad you asked me that,” to buy time and organize responses. Astute guests will know, but it still smoother than “ums” and “ahs”.
15. Never plan gestures. Any gestures you use should be an extension of your message and the real emotions that message conveys. Planned gestures always look phony, because they do not match other involuntary body cues.
16. Arrive early. Never fumble with software or equipment while people are waiting. Scope the room early, run through your slide show, and identify any potential problems. Verify early that all electrical outlets and devices are functioning properly.
17. Practice your speaking skills. Practice instills competence and confidence. If possible, practice with the microphone. Some require that you speak from one angle. Other microphones absorb sound from different directions, but are prone to feedback.
18. Project your voice. Do not yell. Stand up straight and let your voice resonate on the air from your lungs rather than your throat, and you will produce a louder and clearer sound. Vary the tone of your voice and dramatize if necessary. If a microphone is available, adjust and adapt your voice accordingly.
19. Know when to apologize. Apologize only when you have done something wrong. Never apologize for nervousness or a lack of preparation time. Most audiences will not detect your anxiety, unless you draw attention to it. Apologize when you are late or shown to be incorrect. Confidence will promote audience trust, but arrogance will erode it.
20. Be the Audience. When preparing your presentation, think from the audience’s perspective. What might they not understand? What might seem boring? As an audience member, “What’s in it for me?”
21. Know when to stop talking. Conclude your presentation by summarizing your main points. Follow with an interesting remark or an appropriate punch line. Leave your audience with a positive impression and a sense of completion. Do not belabor your closing remarks. If there is time remaining, take questions, thank your audience and sit down.

Let me know if you have any to add!

Scrum goes Green

Dan Greening is doing an incredible job explaining Scrum in no nonsense terms.

Scrum is a software management technique with high transparency, adaptive control, reasonably accurate release forecasting, and high productivity. However, because Scrum exposes marketers and developers to greater visibility and accountability than traditional waterfall approaches, and because it requires different management structures, some organizations encounter resistance implementing it.

There is much, much more on his site.

Check it out.

15 Scrum facts that can make or break your team

If you follow Scrum, it can work miracles in your organization, but I've explained many times before that it is far from being a silver bullet. Without making the effort to built and maintain a solid team, Scrum is completely useless.

Scrum is a tool. 

Use it properly, and it will accomplish what is was designed to accomplish.

Abuse it, and you will fail.

To confirm that this is not news to anyone, I offer Scrum Founder Ken Schwaber's text on the subject:

Scrum is Hard and Disruptive!

1. Scrum is a framework for iterative, incremental development using cross-functional, self-managing teams. It is built on industry best practices, lean thinking, and empirical process control.

2. Scrum is optimized for high yield product management and product development. Scrum is particularly appropriate for high risk, complex, large projects and can be used when other parts of the endeavor are hardware or even waterfall development.

3. If waterfall suits current needs, continue using it.

4. An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization.

5. Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctions that restrict its competence in product development and management.

6. The iterative, incremental nature of Scrum puts stress on the product development organization to improve its engineering skills and on the product management organization to optimize the return on investment of every release and project. The phrase, "That can't be done here" really means that it will be very difficult to do so. The gap between current practices and target practices is a measure of incompetence and competitive risk.

7. The use of Scrum to become an optimized product development and management organization is a change process that must be led from the top and requires change by everyone within the enterprise. Change is extremely difficult and fraught with conflict, and may take many years of sustained effort. Turnover of staff and management can be expected.

8. The most serious impediments to using Scrum are habits of waterfall, predictive thinking over the last twenty to thirty years; these have spawned command and control management, belief that demanding something will make it happen, and the willingness of development to cut quality to meet dates. These are inbred habits that we aren't even aware of anymore.

9. The focus of using Scrum is the change from old habits to new ways of doing business. Scrum is not implemented or rolled-out as a process; it is used to foment change.

10. Scrum is not a methodology that needs enhancing. That is how we got into trouble in the first place, thinking that the problem was not having a perfect methodology. Effort centers on the changes in the enterprise that is needed.

11. Iterative, incremental development is much harder than waterfall development; everything that was hard in waterfall engineering practices now has to be done every iteration, and this is incredibly hard. It is not impossible, but has to be worked toward over time.

12. Managing a release or project to deliver only the highest value functionality and not deliver the rest optimizes value [and] is the job of product management and customers.

13. Self-managing teams are extremely productive. When they work closely with the customer to derive the best solution to a need, they and the customer are even more productive.

14. A team consists of people under pressure to do their best. Conflict is natural and the team needs to know how to deal with the conflict and have resources to draw on when needed.

15. The role of an enterprises management changes from telling people what to do to leading and helping everyone do their best to achieve goals. People aren't resources and managers aren't bosses.

Only 12% of all software companies leverage Scrum

You might recall my complaints regarding Axosoft OnTime's advertised support for Scrum and its short-comings.

This week, Axosoft conducted a survey and determined that I was right.

"...Scrum is one of the top methodologies getting adopted by teams. At Axosoft, we’ve been very intrigued with Scrum and the philosophy behind it. Scrum is very much inline with our own development philosophy, and we hope to improve OnTime even more so it addresses the needs of Scrum teams even better in the future."

They also discovered that most software companies are not using Scrum.

Now, you understand why Decade Software is surpassing our competition like never before.

What do you mean 'no commitment'?

When I read Ken H. Judy's post title—Stop calling it an estimate. Stop pretending it’s a commitment.—I launched Windows Live Writer ready to attack.

Reading on, I realized it was one of those tongue-in-cheek titles that trick us into reading blog posts.

Ken says...

"Setting an achievable target and owning that decision, communicating the rationale for your decision and having that rationale inform your priorities earns trust and rallies a team to deliver.

Don’t set arbitrary targets. Don’t burden yourself with unnecessary risk, demotivate your developers and thoughtlessly constrain the value built into your software.

Do set meaningful targets. Take calculated risks, manage costs, partner with your developers and know what and when you need to deliver to your customers.

It’s not an estimate. The developer cannot assume your risk.

It’s not a commitment. You’ve got to earn that."

Now, maybe you still see Ken's last statement above as controversial? If so, you have much to learn about truth, trust, and transparency.

Of course, no one in the Scrum trenches would disagree, but on the road to the statement above, Ken has much to say about estimating in general—an area that always prompts a debate or two and is well worth a read.

How not to hire a developer

This is from a job posting I found on the net...

"Knowledge of agile development methodologies (e.g. SCRUM, RUP).
A BS/MS degree in Computer Science or related technical field is required...One of our guiding principles is no meetings across the team one day a week—great for heads down work and potentially where you do your best work."

This is a place I would never work.

Let's look at the problems individually...

"Knowledge of agile development methodologies (e.g. SCRUM, RUP)."

Any shop that thinks that Scrum is an acronym and that this project management tact somehow equates to the Rationale Unified Process development methodology has no idea how to succeed.

"A BS/MS degree in Computer Science is required."

This requirement has always been one of my favorites, and my perspective on the issue is likely to offend many among you.

I have a degree, but outside of using Pascal when I worked in Delphi, most of my management and development skills were acquired in the trenches or with my head in a book—not during those years I spent working three jobs, walking around like a zombie, memorizing lecture notes, and drinking beer.

Frankly, I have seen developers without degrees who work circles around some who do. Professionalism and dedication to learning out-produces a piece of paper with your name on it any day of the year.

"One of our guiding principles is no meetings across one day a week."

Meetings equal communication. If your meetings are counter-productive, fix that problem. Don't stifle the team's ability to communicate and collaborate as needed.

"Heads down work is potentially where you do your best work."

Oh yea, this is a place that I want to work. The statement above is one of the most anti-team statement I have ever heard.

It's like that old saying...

"One of us cannot think better than all of us."

Working in a vacuum almost always guarantees that a better idea was available but not considered—and it certainly guarantees rework.

I'll bet this company has a sign on the wall that says:

"Do more with less."

 

(Before you ask, Kevin—No, I did not find this listing, while looking for a new job. I have the utmost respect for my team, and I am very proud to be working with them. Give us another mountain to move, and we stand ready.)

No rest for the Scrum warriors

Over at Elegant Code, David Starr seems to be talking about our office...

"Scrum has finally been recognized as an excellent team management model that supports agility. It is also prone to fracturing at large scale and must be held together with more pressure at large size. It takes more than Scrum to deliver on the whole promise."

And about my team...

"Test Driven Development is a wonderfully lean practice that has genuinely matured to a standard engineering practice.

Who can argue with the constant attention to quality? Now that we can agree this is how to do business, we are simply evolving the technique rather than arguing about whether it has value.

Good stuff."

He also offers some warnings that almost applied to our teams...

"I cannot count the number of times people have represented their practices as 'Scrum-like'. I commonly ask, 'Did you start with Scrum and modify it to fit your shop?'

'No,' is the common answer. 'We read the books and picked the parts that seemed to make sense for us.' "

I laughed out loud when I read this, remembering how hard we fought off Scrumbut in the early days with my team—and more recently in our Design and Client Services teams.

However, David's warning is an important one. If we get lazy, if we start sinking back into our old processes, all of our successes could vanish in a heartbeat.

There is no rest for the Scrum warrior. One must be ever vigilant to ensure that the process machine is well oiled and humming quietly.

Thanks for the reminder, David!

Learn Scrum for a mere $2,200.00 plus airfare to Sweden

Take a look at this...

 

Scrum Leadership Summit
When? October 20 - 22
Where? Stockholm, Sweden
How Much? $2,200 (USD)

 

 

 

More Information:
http://www.scrumalliance.org/events/6--stockholm-scrum-gathering

This will be the first time that both Ken Schwaber and Jeff Sutherland will be together at a Scrum Gathering and on a panel to take on all questions. Space is limited so if you can make it to Stockholm we suggest you register early.

Ken and Jeff are great guys, and the Scrum world owes them much.

In fact, I would love to go there and speak with them myself.

...but if your goal is only to understand Scrum, buy their books instead—and then get to work delivering.

Scrum is not a difficult tool to use, and it is extremely fast to learn, but your time and resources must be spent doing.

There really isn't that much to learn once you understand the basic problems you are trying to solve.

Of course, this doesn't mean you shouldn't go to Sweden anyway. Just find something better to see than a conference hall.

This is the funniest Scrum thing I've ever heard

The following is from the agenda for the Agile 2008 Conference.

It describes one of the classes they offer...

"Come to this tutorial if you are an Agile coach or a Scrum Master and want to let your teams self-organize. They just don’t become self-organizing on their own."

For a mere $1,999.00, you can attend this conference and find out how to organize your self-organizing team.

Give me a break!

Scrum is common sense.

Attend one Scrum class if you need to—I do have two Scrum certifications—but once you understand the fundamentals of what works and what doesn't, move on, and get the job done.

Unless you're just looking for a tax write-off, stop wasting company money on consultants and conferences.

Once you understand the basics of creating a perpetual team—be it Agile, Scrum, Six Sigma, or Super Process Come Lately—there is simply nothing else to learn.

Get out there and make it happen.

Game developers embrace Scrum

In an interview this week, Relic General Manager Tarrnie Williams tells Will Wright that Scrum is the most widely used management methodology for game programming.

"We use Scrum.

That’s the way we manage our projects and we really like it. We’re big fans.

We’ve done our last three productions with it; Company of Heroes was done with it.

We transitioned midway through Dark Crusade, Soulstorm—although it was an external project. Certainly our end game was done that way.

Opposing Fronts and Dawn of War II were also done with Scrum.

Those projects have been finished on time, on budget with little or no overtime."

Eventually, it seems, all development teams everywhere will be Scrum shops, as those who Scrum are consistently out producing those who do not.

As more and more teams outside of software development begin to understand why Scrum works, the same will be true of other industries.

I don't expect all industries to endorse Scrum itself, but once they understand the problems that this tool solves for them, these industries will likely adopt other Perpetual Team methodologies.

If they do not, they will likely lose their businesses to those who do.

Axosoft OnTime does not support Scrum out of the box

In spite of what Axosoft's sales demo and their Google Ad says, Axosoft OnTime does not support Scrum out of the box, and according to the company's owner, they never intended for it to.

However, they do insinuate that OnTime can be easily configured to support Scrum.

This is not entirely a true statement. 

Since the last time I mentioned this, I've gotten several e-mails asking for clarification...

"How can one of the most successful Scrum shops out there, be using daily a product that doesn't support Scrum?"

Firstly, let me say that I love OnTime.

It's very intuitive, and it works well for us, but the tweaks we had to make to support Scrum went far beyond simple configuration.

To use OnTime with Scrum, we relabeled "Features" as "Product Backlog", "Tasks" as "Sprint Backlog". We track Impediments through Incidents, however we did not relabel Incidents, as Incidents are also used by customer support. We leveraged user-defined fields to denote teams and members and used the workflow steps to drive QA and customer interaction.

The major drawbacks are...

• There reporting tool cannot be used to create burndown charts. We create them all using Microsoft Reporting Services and have the automatically e-mailed to team members. We also had to store some data outside of their database tables, as the historical data needed for burndown charts is not tracked by OnTime.
• The Customer Portal does not include Tasks, so Sprint Backlog Items cannot be viewed by customers acting as members (either Pigs or Chickens) of your Scrum team. We workaround this by showing OnTime in webinar standup meetings and automated reports.
• There is no support for calculated user-defined fields. We had to create a trigger on the database to calculate time remaining.
• Some of their fields (like Estimated and Actual Duration) are not used by Scrum, but OnTime's canned reports, Quick Add Task Bar, etc. expect these fields to be used and cannot be redirected to use user-defined fields.

Everything else—with the aid of a few user-defined fields and custom workflows—works perfectly.