Software Best Practices

Who is NOT Happy

Earl Beede — Wed, 24 Feb 2010 21:23:19 GMT

That should be the real question that any project should ask. Far too often the purpose of project work is to make lot of different customers happy. We get requirements from every Tom, ***, and Harry, from the business, from marketing, from sales, from the technology gurus, from the people who will have to maintain the product (OK, we DON’T get requirements from them), and all these requirements get mashed together into a big fat requirements document.

Then we go to build the product and someplace in the middle-to-late development cycle we are shocked, shocked I tell you! that for some reason we don’t have the time and the budget to build all those requirements. So we start de-scoping, deferring, and deleting things that, up to a moment ago, were “required”.

As an aside, when did “require” become optional? Obviously if we choose to release without having all the requirements present, then those requirements are not “required” by any sense of the word as I understand it.

Where were we? Oh yes, despondent at the deluge of delisting requirements (I think I am running out of “de-“ words). The biggest issue in all this is trying to decide (ah, one more) which requirements weren’t really requirements in the first place but pseudo-requirements; wishes in requirements clothing. We hold meeting after meeting prioritizing and re-prioritizing the requirements to try to find some “low” ones to chop off. Only, everybody knows that if they even mention that the requirement source could somehow live and the company survive another quarter without their requirement, onto the chopping block it goes. So of course everybody claims the fulfillment of their requirements are the sole reason people on this planet exist.

Meanwhile the individual contributor at the bottom of the corporate hierarchy is asked to sort all this out. From all of us who have been there before: Good Luck.

This problem is so common but it really is a form of corporate malfeasance. The people at the top have not decided who this project will NOT make happy. That is just as important as who it WILL make happy. The sad truth is that we can not make everybody happy. If do not make decision early, we will waste time and money throughout the project and we will release something that will please no one.

To be clear: any given release of a product can make one customer class happy, the rest you try not to make angry.

If there were a way to make just one product that made everybody happy, the car makers, the shirt makers, heck, the toothbrush makers would have figured this out and there would be just one perfect toothbrush. But there isn’t because you can’t.

So at your next product definition meeting, instead of saying all the cool features your product will have and how people will feel their life is complete just because they had an opportunity to touch it, how about picking one customer class who this product is for and then listing all the customer class “likely suspects” who will not be happy but who we will try not to piss off.

Then sit back and see how much easier the entire development effort becomes.

Lean Software & Systems Conference Program Announced

Agile Management Blog — Sat, 20 Feb 2010 00:00:00 GMT

The Lean Software & Systems Conference program has been announced. Each of the 3 days is packed with great content describing how Lean is being adopted and leveraged to generate real business benefits. As with the Miami conference in 2009, the focus Read More......(read more)

Kanban Coaching Workshop Chicago in May Announced

Agile Management Blog — Sat, 20 Feb 2010 00:00:00 GMT

I've just announced my third public Kanban Coaching workshop in the United States for May of this year to be held in downtown Chicago. I've been collecting some useful blog posts from people who've attended previous sessions... Rachel Davies Read More......(read more)

Facebook / LinkedIn importers

Joel on Software — Thu, 18 Feb 2010 09:05:00 GMT

New StackOverflow developer Kevin Montrose (6,878 reputation) added a neat feature to the career site that makes it a zillion times easier to file a CV if you’ve already put in your job and education history on LinkedIn or FaceBook. Try it out . Need Read More......(read more)

Construx Job Opening: Software Development Trainer/Consultant

Steve McConnell — Wed, 17 Feb 2010 01:12:25 GMT

Construx is looking for a trainer/consultant. Construx has a fantastic staff and unmatched benefits. For the well qualified person who wants to do excellent work in a highly stimulating environment, it is a dream job -- which is why we've been recognized as the Best Small Company to Work for in Washington State twice. Here's the official job posting: Construx is seeking an experienced software engineer to provide training and consulting services with an initial emphasis on training ("Technical...(read more)

Raising money for StackOverflow

Joel on Software — Sun, 14 Feb 2010 21:21:00 GMT

A few people heard me on This Week in Startups (starting at 15:45) asking Jason if we should take money from the first VC who fell into our laps, or spend time doing the Sand Hill Road rounds, meeting more VCs, and doing a road show for the other firms Read More......(read more)

Headcount

Joel on Software — Thu, 11 Feb 2010 22:12:02 GMT

In the early days of a technology startup, you tend to have a lot of software developers, and you feel like you could never have enough. If you hire sales and marketing staff too early, they don’t really get much traction, and you may start to think that Read More......(read more)

Without Support You Will Fall

Steven M. Smith's Being Effective — Fri, 29 Jan 2010 18:10:38 GMT

History provides lessons for teams. Let’s take the time to explore a few of them. This post explores patterns that I see resulting from the interaction of ability, demands and support. Let me explicitly state what I mean by those variables – Read More......(read more)

Why testers?

Joel on Software — Tue, 26 Jan 2010 16:04:00 GMT

My sister got her kids a little puppy, and they’ve been trying to train it. To live with a dog in the house, you need to teach it not to jump on people, not to poop in the house, to sit on command, and to never, ever, ever chew on the iPad. Never. Good Read More......(read more)

Rocket Surgery Made Easy

Joel on Software — Mon, 25 Jan 2010 16:21:01 GMT

Steve Krug has written a follow up to his usability classic Don’t Make Me Think . The sequel, Rocket Surgery Made Easy , is a terrific, short, concise, fun guide to running simple “hallway” usability tests to improve the usability of your software and Read More......(read more)

A little less conversation

Joel on Software — Fri, 22 Jan 2010 15:33:04 GMT

“As companies expand, the people within them start to specialize. At such a point, some managers will conclude that they have a ‘keep everyone on the same page’ problem. But often what they actually have is a ‘stop people from meddling when there are Read More......(read more)

2010 ECSE Meeting Topics Announced

Steve McConnell — Tue, 19 Jan 2010 20:46:22 GMT

The 2010 Executive Council for Software Excellence (ECSE) meeting topics have been announced. They are: January Optimizing for Innovation February Accelerating Organizational Change March Successful Leadership in Software Development April Managing the Release Process May Managing "Core" Development (aka "shared services" or "foundations") June Succeeding with Crunch Mode Projects July The Business of Software Development August Summer Break September Working Effectively...(read more)

Tripwire Removal

Steven M. Smith's Being Effective — Mon, 18 Jan 2010 05:11:00 GMT

I have rules. You have rules. Teams have rules. Rules trip up both individuals and teams causing unintended consequences. We learn rules about such things as what we must do, what we can question, and what we can say. A rule dictates behavior. But when Read More......(read more)

Stop that Mole Now

Steven M. Smith's Being Effective — Fri, 15 Jan 2010 00:10:33 GMT

Do you have a mole undermining the work of your team? Someone who constantly complains privately to any teammate who will listen but refuses to bring that same complaint publicly to the team? Someone whose actions are destroying teamwork? A mole erodes Read More......(read more)

It Works for You: It Doesn’t Work for Me

Steven M. Smith's Being Effective — Sun, 10 Jan 2010 20:18:05 GMT

When you coach another teammate, keep in mind that what works for you may not work for me. Let me share an example – a service I offer is coaching people on how to more effectively lead team meetings. Whenever a team is exploring a topic, there Read More......(read more)

What is Leadership?

Steven M. Smith's Being Effective — Tue, 05 Jan 2010 00:26:00 GMT

How do I define leadership? Leadership is the ability to adapt the setting so everyone feels empowered to contribute creatively to solving the problems. Leadership is an ability, meaning a leader has a capacity to do something through talent and skill Read More......(read more)

Why Requirements Weren't More Prominent in Construx's Classic Mistakes Survey

Steve McConnell — Mon, 04 Jan 2010 21:04:31 GMT

A reader of our 2008 Classic Mistakes White Paper made the following observation: I work in the Aerospace/Defense industry and have read your article called Software Development's Classic Mistakes 2008 dated July 2008. I am most interested in questioning the results of your most damaging classic mistakes overall that is tabulated in Table 8. I have read that up to 70% of project failures can be attributed to incomplete and poorly communicated requirements. Furthermore, the root cause of more...(read more)

Secret language

Joel on Software — Wed, 30 Dec 2009 10:01:01 GMT

Microsoft Careers : “ If you’re looking for a new role where you’ll focus on one of the biggest issues that is top of mind for KT and Steve B in ‘Compete’, build a complete left to right understanding of the subsidiary, have a large amount of executive Read More......(read more)

Organizing the Team

Steven M. Smith's Being Effective — Tue, 29 Dec 2009 21:25:39 GMT

Workshop When you are a member of team, what hopes do you have for productivity? My hope is for synergy, by which I mean team productivity that is clearly superior to what the sum of the individual members’ productivity might have been working separately Read More......(read more)

Protecting the Team

Steven M. Smith's Being Effective — Mon, 28 Dec 2009 19:49:52 GMT

Workshop A vital task for a successful team is to extend membership to the right people and deny membership to the wrong people. If you add or persist with the wrong people, the team will fail at some level. Feelings about who is excluded cut deep. Talk Read More......(read more)

Seeing the Organization Anew

Steven M. Smith's Being Effective — Mon, 28 Dec 2009 19:10:26 GMT

Workshop Does your organization want help analyzing its intergroup dynamics? Does your team want help diagnosing its own intepersonal dynamics? Do you want help interpreting the state of your relationships with other members of the organization? The typical Read More......(read more)

Integrating Your Personal Board of Directors

Steven M. Smith's Being Effective — Sat, 19 Dec 2009 22:23:34 GMT

Workshop Each person has their own personal board of directors. The board members are the parts of ourselves that are constantly interacting inside our head. If your board members constantly bicker and fight, these inner conflicts manifest themselves Read More......(read more)

Managing Yourself, Managing Meetings

Steven M. Smith's Being Effective — Sat, 19 Dec 2009 20:49:06 GMT

Workshop Is your time being wasted in meetings? For example, you join a problem solving meeting attended by the right six people. But the discussion wanders aimlessly and contributes little to the solution. You feel your time was squandered and wish you Read More......(read more)

Change: Knowing When, Knowing How

Steven M. Smith's Being Effective — Sat, 19 Dec 2009 20:34:54 GMT

Workshop Kurt Lewin said, “There is nothing so practical as a good theory.” A gift from pioneering family therapist Virginia Satir is a good theory about how people process change. The Satir Change Model describes the: five major stages of Read More......(read more)

Obie Fernandez’s Experience

Steve Smith's Being Effective — Sat, 19 Dec 2009 01:11:16 GMT

Check out the blog post, What does Quality mean to you?, Obie Fernandez, CEO of Hashrocket, wrote after participating in a workshop I led for his organization. The workshop was full of energy and fun. I hope to show portions of the video they shot of Read More......(read more)

Why Experiential Workshops?

Steve Smith's Being Effective — Tue, 15 Dec 2009 00:17:17 GMT

I lead experiential workshops. Why? You will learn more from an experience than a lecture. And the learning will stick. Experiential means you participate in simulations rather than sit in a dark room watching a slide show and listening to a lecture. Read More......(read more)

Let’s stop talking about “backups”

Joel on Software — Mon, 14 Dec 2009 10:30:01 GMT

Is your desktop backed up? Did you backup that server? Are your backups on a different machine? Do you have offsite backups? All good questions, all best practices. But let’s stop talking about “backups.” Doing a backup is too low a bar. Any experienced Read More......(read more)

Stack stats

Joel on Software — Sun, 13 Dec 2009 17:57:01 GMT

The higher someone’s Stack Overflow reputation, the more likely they are to have submitted a CV to Stack Overflow Careers : This is not entirely surprising, of course: the more time someone has invested in Stack Overflow, the more likely they are to Read More......(read more)

Usability Collateral Damage

Earl Beede — Fri, 11 Dec 2009 19:51:44 GMT

Astute followers of my blog (Hi, Mom!) will have noticed that all of my previous posts are now attributed to “Anonymous”. Same as my forum responses to date. Why? Well, I accidently deleted myself from the site.

“Smooth move, ex-lax,” my mom would tell me if she actually did read my blog.

A little background. This site has attracted the attention of a (some?) nasty little bot that is adding a lot of fake members. The controls in the then-expensive now-outdated software package we use give me little ability to stop them and keep an open site. My control plan was to delete them as fast as they showed up.

Not a problem but the software only allows me to delete one at a time. Not only that, but after it deletes a bogus member, the software refreshes the web page, resetting the order of members to an alphabetical list. The bot was not cooperating by naming all the faux members “aaaaa”.

So my procedure was sort, select, delete; sort, select, delete; and so on. Now I could have written a macro to do this but the software often didn’t finish the delete of one fake member until I was three or four additional zombie members to delete down, then a bunch would disappear from the site all at once.

On the fateful day of my own suicide deletion, in addition to the mind numbing repetition of deleting, oh, 50 or so of the buggers, I was also fighting a window placement that put my needed delete choice off screen. That is, a popup window would popup half off screen and nothing I could do could get it back on screen.

So it was me vs. the machine and damn if I was going to loose.

I lost.

Well, I DID get the delete choice back on screen but the software also did a resort of the member list and instead of deleting “Free Movy Downloads” I deleted myself. I actually had a moment of the little “victory dance” of getting the delete choice back before the, “OH #*%!”.

That, I think, is the essence of usability collateral damage. We get completely engaged in getting the software to do what, frankly, it so obviously should do in the first place that we miss some ramification of our actions.

That is partly what happened with the infamous Therac-25. Technicians, who got a lot of meaningless error messages, still had a job to do and pressed buttons away. Unfortunately, the usability collateral damage there was several people’s lives.

Alan Cooper likes to point out the most developers are really lousy usability designers. The only worse usability designers, in my opinion, in general, are the business partners that give developers the “requirement” to present the interface just like the partner wants. Both are ripe for usability collateral damage.

I agree with Cooper that usability, like project management, like business analysis, is a discipline that needs its own focus. Breathing is not enough qualification for these roles. The damage of screwing up these areas are just too high.

And, please, warn me if I am about to delete myself!

New Site for Kanban Beginners

Agile Management Blog — Thu, 10 Dec 2009 00:00:00 GMT

Janice Linden-Reed has launched a new web site to fill what she sees is a gap in the market. Kanban101.com will provide the beginners guide - just the basics and plain language, no frills explanations of all the jargon, terms and mechanisms in Kanban Read More......(read more)

When and how to micromanage

Joel on Software — Wed, 09 Dec 2009 20:49:02 GMT

“Like most entrepreneurs, Ryan and I are still learning about how to manage people and teams. And we’re both used to hiring very smart and dedicated people who will get things done to a high standard if you give them some general direction and set them Read More......(read more)

Selling Your Ideas to Management

Steve Smith's Being Effective — Tue, 08 Dec 2009 03:28:26 GMT

DAVID: Ruth, I think we should buy the ABC software to track trouble tickets and issues. RUTH: There is no budget for that. DAVID: But it takes me days to put together the information you want about the state of the product. And without an automated collection Read More......(read more)

USA Kanban Coaching Workshops

Agile Management Blog — Tue, 08 Dec 2009 00:00:00 GMT

In February, March and April I'll be repeating my highly successful Kanban Coaching Workshop from London this October. These coaching workshops are designed for experienced agile, project management or process coaches and consultants who are looking Read More......(read more)

Forthcoming Kanban Classes

Agile Management Blog — Tue, 08 Dec 2009 00:00:00 GMT

I'm teaching a few Kanban classes over the next two months in Europe and South Africa. [December] The first of the 2 day classes in Stockholm with Crisp next week [January] Followed by a class in Krakow, Poland and another in Paris, France with Octo Read More......(read more)

Safer Conversations with Management

Steve Smith's Being Effective — Mon, 07 Dec 2009 22:18:48 GMT

You have what you believe is an important thought to share with management. You’re concerned though that management may dislike your message. How do you assess how safe it is to share your thought with management? It’s certainly perilous if Read More......(read more)

Temperature Reading

Steve Smith's Being Effective — Mon, 07 Dec 2009 22:09:13 GMT

Virginia Satir developed this method for discovering a group’s temperature — what we in technology often call the system’s state. A facilitator leads the discovery. He or she keeps the group focused on each agenda item; works with the Read More......(read more)

Coaching Whiners

Steve Smith's Being Effective — Mon, 07 Dec 2009 22:06:22 GMT

Ban whining. It’s destructive communication inside organizations. Why is whining destructive? How can a whiny complaint be transformed into a constructive, actionable proposal? You ask Anthony, who reports to you, “How are things going?” Read More......(read more)

AYE Conference 2010

Steve Smith's Being Effective — Sat, 05 Dec 2009 01:00:00 GMT

Please join me at the annual Amplifying Your Effectiveness (AYE) Conference. I am a conference host as well as a session leader. The focus is around individual, team and organizational effectiveness. Esther Schindler, a reporter for CIO Magazine, participated Read More......(read more)

Programmer search engine

Joel on Software — Wed, 02 Dec 2009 17:24:04 GMT

For as long as I’ve been in the industry, which is, I think, about 74 years now, the problem I’ve had with hiring programmers was not interviewing them or deciding if they’re smart—it’s been finding them in the first place. What I’ve dreamed about is Read More......(read more)

Announcing Lean Software & Systems 2010

Agile Management Blog — Sun, 15 Nov 2009 00:00:00 GMT

The first Lean Software & Systems Conference will be held in Atlanta, Georgia, USA between April 21st and 23rd 2010. Registration and the Call for Papers is now open at atlanta2010.leanssc.org The first 50 registrants enjoy a super early discount Read More......(read more)

Cobblestones On The Road to Perdition

John Clifford — Sat, 14 Nov 2009 04:35:30 GMT

The more I work with companies that are struggling with Scrum, the more I’m starting to believe that ‘hybrid’ Scrum adoptions, where people pick and choose which Scrum practices to follow and which to ignore, invariably lead to failure.

Whoa! you say… Wait a minute! Agile is about doing what is right, not following a process! It says so in the Agile Manifesto! “Individuals and interactions over processes and tools!”

Listen up, Sparky! The Agile Manifesto has to be taken in context, not in isolation. We value processes and tools unless they interfere with individuals and interactions. That is not the same thing as dismissing processes and tools because we value individuals and interactions. Remember, there is value in the items on the right. Too many teams use the ‘left over right’ emphasis to justify haphazard adoption of Scrum, resulting in The Dreaded Plague Known As Scrum-But. As in, “We’re doing Scrum, but we’ll finish testing at the end of the release,” or “We’re doing Scrum, but we have a weekly standup because it’s more efficient.”

How do you Scrum-But? Let me count the ways…. I think the variations are infinite, but here’s some I’ve run into in just the past three months:

No sprint retrospectives
No iterations! (the team was following a quarterly stage-gate plan under a deterministic methodology)
No assigned Scrum Master (people would take turns being called ‘Scrum Master’ and perhaps running specific meetings on some indeterminate schedule), leading to a Product Owner who came in and changed the sprint backlog at will because no one owned ensuring adherence to the Scrum process
No sprint reviews, with the team deciding if a backlog item was done or not as a matter of opinion/consensus
No sprint burndown chart… of any type… and no tracking of velocity (“What’s velocity?”)
No self-assignment of tasks and a ‘Scrum Master’ who was creating the sprint backlog and assigning tasks to team members
No defined product backlog and a Product Owner who abdicated his role by shoving all backlog work onto the team (the team would spend the first several days of a two-week sprint creating the sprint backlog with time estimates)
etc.

One thing that all of these teams had in common: they were all failing to some extent, and some were failing spectacularly. Many blamed Scrum, saying “Scrum doesn’t work!” As if blaming a process for your failure when you’re not following the process somehow makes the failure okay, because it’s beyond your control. It’s Scrum’s fault!

But you don’t understand! We can’t change completely over to Scrum all at once. The team will never accept it! We have to ease our way into it! It requires too much common sense! And besides, our management would never support adopting full-fledged Scrum. We have to do it this way. Be reasonable!

Horsefeathers! (This is a family blog.) Whenever I hear this, what I’m really hearing is We don’t understand what Scrum is, how to do it, or why the minimal Scrum processes and practices are mandatory, because we don’t understand the why. And I hear the undercurrent thought, too: We’re afraid. We’re afraid we’ll fail because we’re not sure how to do it, and we don’t trust ourselves or our fellow team members.

What is Scrum, anyway? Is it just another way of doing your job? Of project management? Of organizing and assigning work? Doesn’t Agility really mean picking and choosing what is best for your organization?

I could (and should) do an entire blogpost on the meaning of Agility, but here it is in a nutshell: Agility is the ability to respond effectively to change. That’s it. Agility doesn’t mean you don’t have to plan, or you don’t have to follow a process, or you don’t have to be disciplined. Being Agile requires all of these, just as anything worthwhile… relationships, career success, success in sports, proficiency in music, etc… requires thought, effort, and discipline.

What is Scrum? It’s three roles, four meetings, and two levels of commitment. What are you saying about yourself or your organization if you’re not willing to try to follow a minimal process with three roles, four meetings, and two levels of commitment? Why is picking and choosing from those minimal processes and practices so devastating to effectiveness? The first reason is because if you haven’t run Scrum for a while and gotten really good at it, you almost certainly have no idea of the why behind each specific process and practice. You may read a book, or take a class, but you won’t get it, just as you could read a book about how to ride a bike but until you get out there and try, and fall, and get up and try again and again, you won’t get it. I understand the fear of change, and the reluctance to go outside one’s comfort zone, but success requires the courage to try. Yes, “a ship in harbor is safe, but that is not what ships are built for.” If you’re not willing to step up, to be serious about developing software, then perhaps this is not the career area for you.

Let’s look at the why behind some of the pick and choose adoption decisions:

Why do we need to hold sprint reviews after every sprint? Because working software, not a Gantt Chart, not a checked-off To-Do list, and certainly not written code, is ultimately the only true measure of progress.
Why do we need a sprint retrospective after every sprint? Because unless we take the time to examine the effectiveness of our engineering processes, we will never improve them, and we will never get better at delivering software if we don’t change how we do it.
Why do we need a sprint burndown chart when we’ll know if we’re done at the end of the sprint anyway? Because sprints, like projects, don’t fail all at once at the very end; they fail a little each and every day. The burndown chart gives us a mechanism to detect difficulties early while we can still take effective action to correct the problem and prevent the failure.
Why can’t we let the Scrum Master act as a project manager or team lead and assign task to individuals? Because we are substituting the judgment of one brain (the Scrum Master’s) for the collective judgment of a lot of brains (the teams’), and regardless of how smart the Scrum Master is, there is no way that he or she knows more about every single aspect of the work than the entire team. Additionally, the team will only grow if given the opportunity, and solving their problems eliminates the opportunity for growth.

And so on. Leaving out these and other processes and practices breaks the paradigm and removes the opportunity for continuous improvement of the product and the process. Why would you want to do that? Scrum is three roles, four meetings, and two levels of commitment, but it’s more. Scrum is an organizational change metaprocess disguised as a project management process wrapper. Scrum exposes your problems, if you have the courage to follow the process despite what you may discover about your organization, your team, and yourself.

There’s a scene in The Matrix, a movie about choosing which path in life to take disguised as science fiction, where the protagonist is offered a choice: take the Blue Pill and go on in the same way, or take the Red Pill and learn the truth about what is really happening in order to do something about it. Scrum is that choice. You can choose to fail, to continue developing software the way you’re currently going about it, to get the same results you’re getting. As W. Edward Deming pointed out, “Failure is an option.” Or, you can take the Red Pill. You can choose a metaprocess that exposes your failures, and then you can choose to fix them, to do things differently, to do things better. Of course, you can choose not to choose, and that in itself is a choice. Saying you’re adopting Scrum when you’re picking and choosing from the minimal processes in order to avoid the pain of change is just fooling yourself.

Scrum done right is the Red Pill. The choice is yours. Choose wisely.

New Ltd WIP Society Supporter Button

Agile Management Blog — Sat, 14 Nov 2009 00:00:00 GMT

This week at QCon I am launching a new Limited WIP Society supporter T-shirt design. The new design is also available as a button that you can place on your web site to show support for the adoption of Kanban. If you want to use these assets on your site Read More......(read more)

Upgrade your career

Joel on Software — Thu, 05 Nov 2009 08:34:00 GMT

Do you like your job? Do you enjoy the people you work with? Would you want to have lunch with them? Every day? Alex Papadimoulis thinks that Fog Tyler Griffin Hicks-Wright Creek’s free lunches are “cultish,” but everyone at Fog Creek loves them. Maybe Read More......(read more)

Does Slow Growth Equal Slow Death?

Joel on Software — Tue, 03 Nov 2009 19:50:05 GMT

My new Inc. column is up . “For a guy who wrote a book on how to hire great programmers, it’s mortifying how incompetent I’ve been at enlarging the sales team, which, right now, consists of one terrific account executive and a dog. (I’m just kidding. Read More......(read more)

Figuring out what your company is all about

Joel on Software — Sun, 01 Nov 2009 16:51:03 GMT

What is your company about? Recently I got inspired by Kathy Sierra, whose blog Creating Passionate Users and Head First series of books revolutionized developer education. She kept saying the same thing again and again: help your users be awesome . Kathy Read More......(read more)

Still Time For Only Kanban Class in USA 2009

Agile Management Blog — Sun, 01 Nov 2009 00:00:00 GMT

We've had a robust registration for the Kanban class I am giving in San Francisco on November 16th and 17th. We've got quite a few international attendees. Perhaps they are coming into town for QCon later that week? As well as a handful of locals Read More......(read more)

QCon Kanban Track Nov 18

Agile Management Blog — Sun, 01 Nov 2009 00:00:00 GMT

I'll be chairing the Kanban Track at QCon in San Francisco on November 18th . We've got a good list of speakers lined up including Jeff Patton (reprising his presentation from the UK Lean 2009 conference) and Henrik Kniberg with his Kanban vs Read More......(read more)

Adam Bosworth on standards

Joel on Software — Sat, 31 Oct 2009 23:50:02 GMT

Adam Bosworth : “All successful standards are as simple as possible, not as hard as possible.” Required reading. Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board : Great software Read More......(read more)

Capstone projects and time management

Joel on Software — Mon, 26 Oct 2009 19:36:04 GMT

It is amazing how easy it is to sail through a Computer Science degree from a top university without ever learning the basic tools of software developers, without ever working on a team, and without ever taking a course for which you don’t get an automatic Read More......(read more)

Kanban Drives Culture and Organizational Maturity Changes

Agile Management Blog — Sat, 24 Oct 2009 00:00:00 GMT

David Joyce has posted a quite remarkable blog summarizing the results at BBC Worldwide since they introduced the use of Kanban, to drive process improvements, one year ago. Improved Predictability as well as Business Agility Many people will review this Read More......(read more)