Design thinking is about creating the future not just managing the present. It's also about spending more time on value creation than value capture. Bill Burnett, Executive Director of the Design Program at Stanford University recently spoke about design thinking and what questions we need to ask to shift from design to design thinking. Design thinking is a way to find new problems in a strategic manner by thinking about new strategies, new systems, and new paradigms.

Often I get to hear “how much documentation should I do”? How long should be my Sprint Planning or Sprint Retro?

The Daily Scrum meeting is a core practice in Scrum, and one of only three schedule-related practices (the others being the Sprint Planning and Retrospective meetings). Scrum emphasizes the need to minimize overhead, since overhead takes time away from development.

Few people enjoy meetings that waste time in swirling discussions. Fewer still like meetings where their ideas and opinions are solicited and then ignored. Retrospective leaders (and anyone else who leads group discussions) need the tools to help groups think, discuss, and decide effectively. Below are five tips to help you make the most of time spent in retrospectives (and every other meeting).

Don’t we just get frustrated when our estimates or guesstimates on timescales or costs turn out to be different from what actually happens? So how do we improve the accuracy of our estimates?

Agile is more than 10 years old - and I don't mean it's 11.  It's real roots go back at almost 50 years to John Boyd. and his OODA loop (observe, orient, decide, and act).  See Chet Richard's Certain to Win for an entertaining and enlightening introduction.

So much has been written, discussed and argued about the joint life of developers and testers. It seems whenever these two groups meet, there will be more shouting than agreements. Predictably, this is in contrast with what the people are there to do: Work together to provide value to customers.

One reason programmers dislike meetings so much is that they're on a different type of schedule from other people. Meetings cost them more.

The magic of focus and simplicity: Steve Jobs and the Toyota Way

A few years back, I interviewed some of the most successful CEOs in the world in order to discover their management secrets. I learned that the "best of the best" tend to share the following eight core beliefs.

I was recently teaching a Certified Scrum Master class and was told by a student that Scrum didn't work because management still comes and demands additional features or projects and sets or keeps the deadlines and not asking for estimates of how long it will take. 

Last week I asked on twitter how we could describe difference between Waterfall and Agile in one word. As I’m recently doing some research work and find myself often needing to summarise and extract essence of ideas I though this could be an interesting exercise.

On the phone with me today is Alan Shalloway. Alan is founder and CEO of Net Objectives. His company helps organizations transition to Lean and Agile methods enterprise-wide. In the past year, I’ve attended several webinars held by his company and started following him on Twitter where I have found them to be thought leaders across numerous Lean and Agile disciplines.

In this article, Alexei Zheglov reflects on his startup experience and David Anderson’s Kanban method in light of Eric Ries’ lean startup movement. Lean startup’s “build-measure-learn” is a kanban system optimized for response time. Therefore, the kanban method is critical to lean startup implementations. Making the most of both approaches requires understanding how they relate to each other.

I came across a favorite blogger’s post previously.  Tony Schwartz’s “The Magic of Doing One Thing at a Time” offers so many good points, I suggest the read.  BTW: He sounds pretty “Agile” to me.

In 1714, the British government offered a prize for a method of determining longitude at sea, with an award of £20,000 (three million pounds in today’s terms). John Harrison, a Yorkshire carpenter, worked on the project for several decades and eventually in 1761, came up with a design that proved accurate on a long voyage to Jamaica.

I have incredible respect for the signatories of the Agile Manifesto. I believe it to be a great document. I say this for several reasons – the greatest being it created a new space for effective development to take place. It started a movement that has changed the lives of millions.

As I lighten my workload a bit during my “Blog Break” in preparation for my family’s move to San Antonio, I thought new readers might want to check out my post from 2008 titled “A Home Kanban System – Toilet Paper & Paper Towels.” Do you utilize kanban at home?

At Telerik, just like at every other software development shop, we have struggled with the definition of "Done". Throughout the years we've had many definitions of "Done" within teams and individuals:

Do I really think a winning basketball team is like a Scrum Team?

There can be many reasons organizations struggle with their agile adoptions, but often it is because they’re clinging to the idea that only a select few people can be trusted to do the real thinking.  Design decisions are left in the hands of the leads or senior engineers, and so are the estimates. Tasks are then doled out as piecework to the “team resources” (who were recently drafted from the resource pool). Problems that arise are funneled to a leader, who evaluates them and dictates a plan of action.

When folks started moving to agile development around the turn of the century, they first moved away from using certain automated tools. They did this mostly in order to get rid of project management tools and focus on face-to-face communications. This was a reasonable reaction to what had turned into a world of silos and automated workflow management. We developers were ridding ourselves of the mechanisms that produce all of that ceremony and reams of design documents. We would only use index cards and hand-drawn charts on a whiteboard. We didn’t want any tools to get in the way of the real work we were doing.

Ok, I relent. Everyone wants to know why I left and answering individually isn’t scaling so here it is, laid out in its long form. Read a little (I get to the punch line in the 3rd paragraph) or read it all. But a warning in advance: there is no drama here, no tell-all, no former colleagues bashed and nothing more than you couldn’t already surmise from what’s happening in the press these days surrounding Google and its attitudes toward user privacy and software developers. This is simply a more personal telling.

For me, the real miracle of agile is staring us in the face every day, such that it tends to be overlooked sometimes when the essence of such things is being sought, discussed or even “measured”.

John Deere started experimenting with Scrum with a few teams in 2007. By early 2010 we had about 10 teams practicing scrum and many more teams wanting to learn. In September of 2010, we had a product launch planned for January 2011, and we realized there was no way were going to be able to deliver critical new functionality without a substantial change in the way we were working. So we broke down the functional barriers, organized into agile teams, introduced scrum+ to 150+ people over one week, and went “all-in” with agile on that program.  

Word-of-mouth is gold and social media is the vessel we use to promote it, but how exactly is it accomplished?  As businesses we are always looking for ways to lower the cost of acquiring new customers.  It’s simple economics, the lower the acquisition cost the more sales (and money) we make…simple right?  Not exactly. As with most things it’s easier said than done, but if you make it part of your daily customer/employee interaction to give your customers something positive to talk about you go a long way to influencing a higher rate of word-of-mouth, let’s call it your ROE or "Return On Experience."

What’s the first thing that pops into your mind when you hear the term agile development? Is it something along the lines of responsive and adaptive? Did you automatically equate this to responding and adapting to changing software requirements?

In early 2011, a company made a major investment in Agile.  An intentional decision was made from the executive level down to the grassroots that an Agile approach would be used to develop products.  An investment in training, months of coaching, and lots of hard work led to measurable results.

1. Why do you want to do the software project in Agile mode?

A product or service is merely a means to an end. The real deeper value lies in the context, the story attached. I don’t want to own a phone – I want to be able to stay in touch with my friends wherever I go. I don’t want to use a train - I want to be home with my wife and children. I don’t want to use a financial service – I want to do the smart thing and feel more secure about the future by saving money.

I’ll let you in on a secret: I don’t care what letter you put in front of ”DD.” I don’t care so much about how code is written or the ins-and-outs of software development. It’s not because I don’t realize how incredibly important it is – it’s because what I care most about is the value delivered. How can what you do save me time, money and/or frustration? I’m smart enough to know that without you – the incredibly talented member of the development team – my life will go into a tailspin. Nothing will work. I realize and appreciate that what you develop creates value for me.

Maybe you bought your employees a ping pong table or let them telecommute one day a week. Maybe you brought in a massage therapist or offered free fresh fruit in the conference room. Whatever perk you offered, you probably weren't doing it 100 percent out of the kindness of your dear entrepreneurial heart—you also expected your investment to pay off in improved morale and increased productivity. 

A few months back I had dinner with a group of product managers returning from Scrum training. The team had been struggling to find the right process for their organization, and hoped the additional training might identify their internal deficiencies. One of the product managers confided to me in his disappointment that the instructor’s general answer was that they were not being “Scrum enough” – and that their success required adhering to all the principles of Scrum, not just picking and choosing the ones they wanted to adopt.

As an agile coach, I can’t tell you how many times I’ve heard conversations start like the one above. Invariably, coming into an organization to help it improve I find myself establishing numerous coaching relationships with people at different levels of the organization. This network brings me into situations where others share with me the problems they are having with peers, subordinates, bosses, pretty much anyone they may be interacting with at work.

We have always known that Apple [AAPL] is agile, having successively disrupted the music industry, the cell phone sector and the tablet market, as well as itself. But is Apple truly “Agile” in the sense of the Agile Manifesto? Apple is conspicuously absent from the Agile/Scrum/Lean/Kanban conferences. Is it possible that they could be agile, without being Agile?

Agile, a software development methodology born back in 2001, has now entered the mainstream. According to a Forrester Research report issued last month, Agile is not only used in several of the world’s leading companies now but is being applied in areas beyond software development.

See if this sounds familiar: You're on a tight schedule to hit a hard deadline. Slipping the schedule is not an option. The team is working feverishly and functionality is being churned out at a rapid pace. You look at your Gantt charts, project estimates and work breakdown structure created at the project inception six months ago and they all say that everything is fine. Yet despite all of this, you've still got this nagging internal voice asking, "Are we gonna make it?"

On agile projects, the daily standup is one of the ways the team members build trust. The team members complete work every day, and make micro-commitments to each other every day. Making and keeping these commitments builds trust. And, when you’re not all together, it’s just a little more difficult to create that trusting environment; you have to consciously work at it when you’re not all on one location. It’s even worse if you have the testers in one place and the developers in another, and the product owner in yet another location.

Lean & Agile management needs a new breed of managers focused on spawning motivation, supporting team-based work and understanding systems. Here, Esther Derby discusses her views on Lean & Agile management with Kristoffer Nordström of Softhouse.

One day Jip visits Janneke. Jip would love to have a beautiful playground with everything in it. Janneke thinks she can provide in this but first she would like to know what should be in it.

I’ve been struck how little is written about being a great Scrum Master. There is heaps written about Scaling Agile and a lot of great Technical books, but very little on playing individual roles well. The ScrumMaster Tales are intend to fill this gap.

Many of the companies I work with want the benefit of the team effect in software development. The managers in these companies recognize the enormous benefits teams provide to the company–creativity, engagement, learning.

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Does success at the team level always result in success at the organization level? Sanjiv Augustine and Arlen Bankston discuss the Seven Deadly Sins that organizations repeatedly make so you can steer clear of them and benefit from a successful Enterprise Agile Adoption. 

CFOs are increasingly calling the shots, which means CIOs are reporting to them, not the CEO. Do you know how to talk business in a way they'll understand? If you're all about the tech, the answer is no.

This is the second part of a write-up of a talk I gave at a number of conferences last year. The previous post was the Introduction.

The Product Owner is both one of the most important roles in Scrum and often the most difficult to fill. In this post, I will explore a few aspects of successful product ownership that are often done poorly or not at all.

Most often, we have observed that agile implementations fail in spite of putting efforts towards educating the team about Agile principles, training the team on Agile practices, and getting the right people for Agile roles. Have you ever wondered why? There are chances that the culprit is the team itself.  The team could be plagued with several dysfunctions (refer to  “the five the dysfunctions of team” model from Patrick Lencioni). If you discover this in your teams, how would you go about dealing with it? How can we overcome the dysfunctions and thus help the team implement agile successfully?

Over the weekend I came across a pretty cool article from Hubspot that everyone (particularly if you work in marketing) should take a look at. In an age where everyone is talking about the importance and desire to become more agile, Hubspot offers up five great tips to help jump start your marketing department. 

Recently, I heard folks at a few of my clients and at a couple conferences talking about why they are considering moving to using Kanban vs. Scrum.  I have no preference to either method other than choosing the right agile development tool for the job.  My concern derived from what I have heard identifies the beginnings of some myths and also demonstrates some of the hype around Kanban.

I've been working with folks making their transition to agile. One of the hardest transitions is for the managers and technical leaders.

The debate as to whether a ScrumMaster is a full-time or part-time role in an Agile teams has created a lot of discussion in the community in recent months. 

On my journey to become a Certified Scrum Trainer (CST), I’ve met a number of helpful and knowledgeable people. For those of you who may not know, part of the plan to become a CST consists of training with other current CSTs.

One of the most challenging situations involving adopting agile is when doing so in a software shop that has several specialized groups already in place forming silos: development, quality assurance (QA), business analysts (BA), software configuration management (SCM), documentation, architecture, database admin (DBA), and user experience (UX). 

The fact remains that business people need project estimates, and they often need them before software teams have begun iterating. What to do? Daryl Kulak explains how giving a more vague estimate to the product owner is better than using precision to convey a level of confidence we do not have.

Do you get confused about the difference between “user story”, “epic” and “theme”? Whether you're new to agile or a seasoned practitioner, rest assured you're not alone. Mike Cohn provides a back-to-basics reminder, clearing up the uncertainty over what term we should be using when.

It might sound like an oxymoron, but in the 21st century it seems that the most predictable thing is change. Companies organized to deal with change tend to be more successful than those who aren't. Michael Hugos discusses the importance of feedback loops in achieving business agility and continually adjusting to changing customer desires and changing market circumstances.

Do you know the root cause of why so many projects still fail to meet original estimates? Not knowing the velocity of team production. Jeff Sutherland explains why tracking hours completed tells us nothing about how many features can be delivered and when, advocating that the management metric for project delivery needs to be a unit of production.

Developing software iteratively and incrementally the Agile way does not result in a big surprise at the end.

The principle reason that Agile development methods have caught on like wildfire is that they address the root cause of most software development failures.

This item is part of the Agile Manifesto Anniversary series, commemorating 10 years since the signing of the Agile Manifesto. 

InfoQ is far from the only organisation commemorating and commenting on the state of Agile ten years after the signing of the manifesto.

Here are some of the articles which have been published over the last couple of months:

The February edition of PragPub magazine has a series of pieces by ten of the original Manifesto authors titled "Agile @ 10".  The byline states

One thing, at least, is clear from these reflections: What was defined at the Snowbird meeting remains a work in progress. It wouldn’t be agile otherwise.

A common theme from PragPub contributors is the need to focus on the simple principles and disciplines that were the foundation of the Agile movement.  A number of them talk about the "bad" agile implementations that are hurting the perception of agile in the marketplace, they also lament the many formulaic adoptions of the agile practices whithout underlying acceptance of the need to proactively adapt them to local conditions.  

For example Andy Hunt says:

That’s a big part of the picture we haven’t got quite right yet: helping people work out new practices in particular contexts that work well for them. That’s the secret to real agility; it’s not about doing pair programming, or having stand-up Scrum meetings. Anyone can dogmatically follow the practices prescribed by others.
But true agility goes beyond the dogma, beyond the practices. Agility is about adapting; adapting your process, your language, your tools, your team, and yourself to respond to the situation at hand. We need to be positioned to be able to do that in order to fully realize the promise of agility, and maybe even move beyond it.

Ron Jeffries:

Frankly, though, I had imagined more. I had hoped that many people would adopt these ideas, and I had imagined a significant step upward in project success among those who did adopt them. I had imagined the industry really moving up a notch. What happened is that many have adopted the ideas, at least in name, but that few of them have attained anything like the benefit that is possible.

James Greening:

There is at least one new problem ten years after. Now we have organizations that have a few Scrum Masters and proclaim themselves Agile, but that continue to spend months in analysis and design, and similar amounts of effort in test and fix. They have stories and iterations, but ignore relative effort estimates and velocity. Code is deteriorating. Tests are not written. And they wonder why Agile is not working for them.

Jim Highsmith has an article in Dr Dobbs in which he encourages the community to "Keep Agile Going" - he is encouraged by the way that the agile movement has "learned to deliver value to customers faster, how we’ve brought quality to the forefront in ways that haven’t happened before, and how we’ve improved the quality of work places around the globe".

He provides advice on ways to ensure that the agile community continues to move forward: continue to innovate, balance idealism and practicality, reinvigorate our Agile value roots, and unify rather than splinter.

Innovate. I’m encouraged by the continuous innovation I see in Agile: DevOps, continuous delivery, the conversations over technical debt, Lean, Kanban, Agile/Adaptive Leadership, and more. Continued innovation combats the creep of staleness that tends to infect movements after a few years.
Idealism vs. Practicality. As Agile permeates into larger organizations; we have to focus on both idealism and practicality. Many people don’t care much about esoteric arguments — they care about results. Idealism and innovation are absolutely necessary for a vibrant movement, but they need to be balanced with a dose of practicality in organizational transitions.
Reinvigorate. The power and attractiveness of the Agile movement lies in its values as expressed in the Agile Manifesto and the Declaration of Interdependence. The more we can emphasize the dual importance of both doing Agile (practices) and being Agile (values), the better we can move forward on a more solid foundation.
Unify vs. Splinter. As any movement grows, there are times when it tends to splinter and times (sometimes) when it unifies. I appreciated Mike Cohn’s recent Scrum Alliance update in which he said, “We want Scrum teams to look beyond the Scrum framework and experience the great ideas found in our sister approaches of Lean, Extreme Programming, Kanban, Feature-Driven Development, DSDM, Crystal, Adaptive, and more.” Efforts like this to bring the Agile/Scrum/Lean/Kanban/etc. communities together, rather than continue to splinter further, leaves less space for the idiots to exploit.

Dr Dobbs also has an article by Scott Ambler titled "Agile at 10: What We Believe" talking about the 10-year anniversary meeting organised by Alistair Cockburn that he attended.  The participants examined the state of the agile movement and discussed the future direction of the agile community.  Denis Stevens also attended the 2011 meeting and posted his thoughts in a blog entry titled "WHAT’S NEXT FOR THE AGILE MANIFESTO" 

Both Ambler and Stevens talk about how the attendees came to a set of four belief statements:

We, the undersigned, believe the Agile community must:: 

1. Demand Technical Excellence
2. Promote Individual Change and Lead Organizational Change
3. Organize Knowledge and Promote Education
4. Maximize Value Creation Across the Entire Process

Stevens summarises the thinking behind the four statements as follows:

Demand Technical Excellence

 At the end of the day, you can’t deliver value through technology if you are not delivering quality. This category brings in aspects of architectural, engineering, and design. This is still a pressing issue and must be addressed in the community to deliver on the promise of the Agile Manifesto.

Promote Individual Change and Lead Organizational Change

Here is an example of a sentence that we had a broad range of perspectives on. Without adoption by individuals and alignment of organizational governance and management models, Agile won’t deliver on its value proposition.

Organize Knowledge and Promote Education

This isn’t just about the practitioners, it includes the broader business context as well. The community needs to build on the broad body of knowledge that exists within and outside the community – we have to avoid reinventing everything. Diversity of thought is important to the ongoing growth of the community – but we don’t actually do a very good job of intentionally building on the body of knowledge.

Maximize Value Creation Across the Entire Process

Software Development is not an end unto itself. Too many organizations moving toward Agile are focused on just the software development team. This is only valuable to the point that the software development team is the constraint in the organization. We need to learn how to do a better job of defining value and aligning the cadence across the organization and improving the flow of value from concept to delivery.

 The editors of SD Times have declared that the term "agile" is no longer going to be used in their publications, after ten years agile practices are now mainstream and are the way software is now built:

Enough with “agile” already! It’s been 10 years since the Agile Manifesto, and the conclusion is inescapable: Agile methodologies are a key part of the foundational software development universe.

We believe that the broad acceptance of agile software development, and its validation broadly throughout our industry, says that agile is mainstream. That’s not to say that we’re not going to use the “A-word” ever again, but rather we’re going to change how we talk about it. Our intent is to stop treating agile development as something new, unusual, niche or experimental

Where is agile heading, and what thoughts do you have when reflecting on 10 years since the agile manifesto?

Posted by Vikas Hazrati on Mar 23, 2011

Commitment is defined as the act of binding yourself to a course of action. In Scrum, commitment has a strong meaning and Scrum practitioners suggest that authentic Scrum is not possible if people are not keeping commitments. In-spite of this, forums have a lot of questions about commitments not being met. Do we understand the real meaning of commitment?

Jens Coldewey suggested that commitment in an Agile team is the commitment done by a self-organizing team to do a good job. This is a team where the team members are enthusiastic and take pride in their work. Commitment on the number of stories which would be completed or the number of story points which would be delivered is an incorrect form of commitment.

Committing to certain stories or a number of story points is like a surgeon committing to a certain time period in which the patient recovers: you commit to something that is simply out of your control. If a team does not finish as many stories as it thought it would during the planning meeting, it just means that it has responded to change.

According to Jens, commitment to anything, apart from doing a good job with passion violates the Agile Manifesto too. If a team commits to deliver a certain number of story points 'no matter what' and they happen to encounter a change then, there are only two possible options to meet the commitment. Either by putting in extra hours or reducing the quality.

Likewise, John Sonmez quoted that though commitment is an unspoken central theme of Scrum however, in reality the biggest weakness of commitments is that they cannot be followed due to one reason or the other in the real world context.

So, what is wrong with commitments? They cannot be followed. The business doesn’t want to change priorities, but a critical issue comes up. The development team wants to commit to the sprint, but the development team can’t make more code get done faster simply by wanting to. They can add more hours to the sprint, but then they are skewing the velocity. The only way the development teamcan realistically commit to the sprint is to ‘pad’, and that is a very bad word.

Another problem with commitments is the one suggested by Chris Goldsbury. Different people might understand different flavors of commitment. For some it means to complete the stories and tasks in the iteration no matter what and for others it might mean 'trying' to complete the stories and task with the underlying assumption that some of them would move to the next sprint. This subtle difference in understanding results in a huge difference of outcome.

In a similar discussion, Glenn suggested the following definition of commitment

The commitment that a team makes is to work professionally and follow the rules of Scrum. The Sprint end date is fixed. There is no commitment to content. Of course meeting the commitment means many things including getting backlog items done-done. If backlog items remain undone at the end of a Sprint then they go back on the backlog.

Rawsthorne and Shimp described their technique for 'commitment based planning'. According to them, one of the reasons for it to work is that it is not based on sizing of stories. It is rather based on realities and facts at that very moment of time, taking the current situation into account rather than doing a commitment based on story sizing done in the past.

Hence,  according to many people in the Agile community, defining a commitment based on stories and story points does put some checks and balances in places for the validation of the sprint, however the real commitment is still the dependent on the passion of the people and their willingness to win.

March 20, 2011 by MedCity News

Some of the leanest, most efficient operating and emergency rooms in North Carolina hospitals have the automotive industry to thank for their smoother operations.

A growing number of healthcare facilities are incorporating so-called lean manufacturing techniques adapted from Toyota (NYSE:TM). Leannovation, an Apex, N.C.-based company, is one firm bringing such techniques to hospitals. Auto industry veteran Sean Lewis founded Leannovation in 2004, initially targeting other manufacturers before branching into other markets.

Lewis says the techniques of efficiency and continuous improvement can be applied anywhere there are systems in place. In that context, health care seems like a no-brainer as a target market. But Lewis' decision to bring lean manufacturing tools to hospitals was more of a personal decision than a business one.

Several years ago, Lewis' grandfather was hospitalized for what Lewis says was an unnecessarily long time. Lewis' grandfather was administered the blood thinner coumadin. But the times he was given his dosage of the drug and the times when his blood levels were checked were mismatched, leading to an inability to manage the coumadin levels properly. The clinicians administering the drug weren't communicating with those measuring the blood.

"This system needs lean badly," Lewis recalls saying. "That's why I got into health care."

The Toyota Production System, often shortened to TPS, is a system developed by the automaker to boost the efficiency of its operations and eliminate waste. For example, components in the car manufacturing process are not ordered until they are needed, reducing the need to keep items in inventory. In modern manufacturing parlance, this concept is called "just-in-time."

The concept came from TPS, where it's called "kanban," which translates as signboard or billboard. That means workers rely on signs to indicate what to do or how much of a product to order. In fact, many of the lean concepts retain their Japanese names when adapted for health care, as is evident in this video showing how a hospital kanban system works:

Before founding Leannovation, Lewis had spent his entire career in manufacturing, primarily in the automobile industry. He worked first for Ford (NYSE:F), then Chrysler. Each company has a different name for its lean initiative; at Ford, it was the "Ford Production System." But the TPS system originated by Toyota is now widespread throughout the automotive and manufacturing industries in some form.

Lean's benefits are now coming to health care. Terry Krauss, business development representative for Leannovation, says that the benefits come from studying the existing process and finding a way to make it better. Leannovation doesn't have permission to disclose specific clients but, as an example, Krauss cited a regional medical center in southern North Carolina whose OR supply management process was redesigned, saving more than $80,000 per year in expired inventory. When lean techniques were applied to OR scheduling, the hospital was able to take on six more surgeries per week with the same staffing levels working the same hours as before. More surgeries translates into more hospital revenue, he says.

While health care has systems that can readily adapt lean techniques, hospitals do present different challenges compared to manufacturing, Lewis said. When a manufacturing process is improved, the benefit can be immediately seen with results such as faster throughput. Those results aren't always readily visible in health care. Part of that stems from the multiple silos that exist within health care, each with its own territory and power.

Territoriality is evident even within a single hospital where the ER, the OR and the ICU clash over various issues. Compounding the problem is fact that people in one silo often don't see the processes that need improvement in the other silos. Bringing lean to hospitals, Lewis says, is not about making radical changes. It's about changing processes over time, training employees and ultimately, getting the silos to communicate better.

Leannovation isn't the only company pitching lean techniques and it's not even the only company pitching these techniques to hospitals. But while lean has a firm foothold in manufacturing, health care is still a relatively untapped market. That means there should be many opportunities for Leannovation and others. Lewis is betting on it. In the same way that lean became integral to automobile manufacturing, Lewis says lean will become just as important to health care.

"It's going to be system that health care is going to be built around in the future," he said.

Is the mighty concept of agile software development, championed as the better way to develop software by building it in short iterations, striking out, or is it just misunderstood?

Agile development has been experiencing a backlash lately, getting a particular skewering in technology management consultant Daniel Markham's blog entry, "Agile Ruined My Life." Among other things, Markham argues that agile is a marketing term, that conflicting advice is offered on how to do agile, and that "fake success stories" abound.

[ See InfoWorld's November 2010 special report: "Agile programming 10 years on: Did it deliver?" | Stay up with the latest programming insights from InfoWorld'sDeveloper World newsletter. ]

Now, a longtime pioneer of the agile concept has had enough and is taking a stand.

In a recent conference presentation, Jon Kern, a signer of The Agile Manifesto for Software Development 10 years ago last month, defended agile. "It's not agile [that is the problem]," he said. "It's people doing stupid things in the name of agile and then giving agile a bad name."

Developers, he said, should not be stuck on the notion of pure agile, in which they are told they must perform tasks in a specific way or risk not being agile. Agile actually is "is more context-based," Kern said.

"To be an agile developer, it's mostly about being very pragmatic and not dogmatic and really trying to understand the system that you're trying to build as whole," he said at the Server Side Java Symposium in Las Vegas. A core principle is reducing the amount of time between doing something and seeing results, he said.

"Agile is the ability to really move and adjust," and so requires peak performance, Kern stressed. "What we really need to do is either reconnect to agile if you're having issues or connect properly for the first time." Agile requires a lot of thinking, and the particular people working on a project are critical. "People are the number one important ingredient and the number one cause of failures or success."

Critic Markham turns out to be a friend of both agile and Kern. "Jon and I actually became friends as a result of that article," Markham told InfoWorld.com. In fact, he's an active agile coach. "I am a big fan of agile. That's 'little-A' agile, as in principles not rituals," he added.

"The principles of agile are very sound -- tight feedback loops, engaging the customer as an integral part of the team, always adapting, and so on. The problem was that 1) the manifesto is the most overmarketed self-help doc on the planet, and 2) people get caught up in the details instead of operating from principles. They become 'agilistas,'" Markham said.

Markham added he has probably watched 100 teams struggle with agile adoption and worked with other coaches who have witnessed the same thing. "I think perhaps one of the reasons my article resonated so well was that it was from a knowledgeable person inside the community, somebody who has spent a lot of time teaching this stuff. Not from a simple naysayer. As my article tried to show, it's not the core of agile that is the problem -- it's the half-assed way we've taken people who couldn't code their way out of a paper bag and made them experts that is the problem. ... Some of these guys who are famous authors and speakers wouldn't be worth a plug-nickel on a real, live delivery team. The buzz has lost sight of reality."

Agile in game development

By Alex Handy

At last week's Game Developer's Conference in San Francisco, I had the distinct pleasure of sitting down with two of the founders of Bioware. For those of you who don't speak video games, I'll explain who they are. Ray Muzyka, Greg Zeschuk and Augustine Yip sat down in 1995 and decided to update the world of Dungeons and Dragons video games. They started with Baldur's Gate, a graphical D&D game with an expansive, deep story, and with revolutionary graphics and presentation.

Fast forward a few years, and Bioware has gathered itself a reputation as a reliable hitter. The company seems incapable of making bad games, a rarity in the industry matched only by Blizzard and Bungie. Bungie was purchased by Microsoft back in 1999. Blizzard merged with Activision in a multi-billion dollar deal that merged the names as well. Last year, Bioware was picked up by Electronic Arts for a cool US$650 million. Not bad for playing games.

Why am I telling you all of this here, on an enterprise software blog? Because Bioware has a secret super power: the power of agile. I've heard numerous other Bioware employees state that agile was their secret weapon, but last Friday, I got to sit down with Ray and Greg and actually discuss how they implement agile and how it works in an environment where not everyone involved in the process is writing code.

Muzyka said that “clarity of goals is one of the most important things. Whenever you talk to an agile group, you have to have clear goals. You have to know when you're done.”

That's not so easy in a world where your end product attempts to deliver something as metric-squishy as "fun." Muzyka and Zeschuk said that the real secret here is having disciplined experts as team leaders. Zeschuk, specifically, said that these leads then collaborate with underlings to determine how each bit of development fits in with he story, the art and the pacing of the game.

The really interesting thing here, for me, is the integration of artists and writers into the agile process. While the Bioware folks don't go as far as checking in scripts to Subversion, they do include all stakeholders in planning meetings, thus insuring that the coders don't go off and leave writers behind.

"Also, for the big chunks where there's a lot of cross discipline involved: artists, writers, level deisgners, visual effects artists, and many more, it's just been a very effective way to break down the barriers that exist in disciplines," said Zeschuk. "[It] works really well in bringing various disciplines together. Some of our user stories are like, 'Walk from A to B,' but doing that takes 10 people."

Once those stories are written, however, Bioware's pipelines take over. Muzyka and Zeschuk said that the 3D art created for their games tends to exist in a waterfall process, where the artists are simply tasked with "make 100 characters." 

What's the takeaway? Agile planning meetings should include everyone. That means bringing in your business people and your end users, alongside your developers, testers and managers.

As an interesting side note: Ray Muzyka is also soon to play in the World Series of Poker again. In 2006, Muzyka found himself sitting across from Blizzard founder Mike Morhaime in the finals. It's a small world.

Learn More and Watch a video

Looking for agile training that doesn’t assume you already know everything about sprints, stories and backlogs? Tired of webinars full of theoretical concepts that tell you why you should use agile but not how to practically apply it? Do you want to start applying agile principles in your work but don’t know where to start?

Choose from 5 topics, only $99 each, or take the whole series for just $399:

VersionOne’s Agile eLearning series is your fast track to becoming an agile ninja.

Entertaining, experienced agile practitioners

• Learn the how, not just the why
• Collaborative environment
• Education designed to keep you engaged
• Small class size
• All the benefits of being in a classroom without the headache of traveling

What’s so special about this series?

You don’t have time to waste trying to find education resources and grappling with complex theoretical diatribes. VersionOne’s Agile eLearning is designed visually for the way your brain works, not a text heavy approach that puts you to sleep.

We cannot change our behaviors until we internalize "being agile" and align our values to 
the Agile Manifesto and its principles.

Learn how an international, highly collaborative team built a 100 mpg gallon road car in 3 months using 
Agile methods.

AccuRev Releases Breakthrough Research On Obstacles to Successfully Adopting Agile Practices

AccuRev offers recommendations, tools to address pain points

 that limit adoption of Agile

Lexington, MA, January 20 2011:  AccuRev, Inc. furthered its efforts in accelerating Agile across the enterprise today, releasing research that sheds new light on the obstacles software development organizations are facing as they move forward with Agile initiatives.

ASPE and VersionOne are partnering again for the 2010/2011 Agile Salary Survey (http://2010-agile-practitioner-salary-survey.questionpro.com/). 

Last year’s results were astounding and we are anxious to see how this year’s results compare. 

Today’s remote managers are often working in uncharted territory, and we have to find best practices and tips where we can find them- often in unrelated fields. Few fields have blended remote working, technology and diverse functions as well as the software development world. One of the fastest-growing team methodologies is “Agile” software development. What can non-techies learn from this way of working? A surprising amount.

SolutionsIQ develops new technology that assists college students with securing funding in a tough economy

REDMOND, Wash. – December 1, 2010 – SolutionsIQ, a premier provider of distributed Agile software development, and Agile coaching, consulting, and training, today announced it has delivered vital Web site improvements for the Washington Scholarship Coalition. The enhancements to theWashBoard.org have streamlined the process for students in the state of Washington to find and apply for scholarships and funding for higher education.

“Working with the SolutionsIQ team was a very high-quality experience,” said Jeff Nicholls, project manager, Washington Scholarship Coalition. “Because of our close partnership there was a high percentage of ‘getting it right the first time’. The fact that the team was very quick to become familiar technically with the application enabled us to run very quickly and efficiently. SolutionsIQ’s Agile development methods are a great way to incorporate changes and deliver results quickly.”

The new site, backed by local media coverage and a focused marketing effort to get more providers to list their scholarships, has attracted many new student-seekers (a 14 percent increase) and providers (+5 percent) since its deployment in late October. The Phase Two enhancements have generated excitement among providers who are looking forward to posting their scholarships for the upcoming academic year: nearly two-thirds of registered providers surveyed reported a “very good” or “great” experience on theWashBoard.org, and they consider the most important features of the site to be the fact that it is free, Washington-focused, and now has a range of flexible administrative options.

“We were pleased to help the Coalition with functionality improvements,” said David Wylie, director of Agile Development Services for SolutionsIQ. “It’s very important to match students with available scholarships, and the technical improvements we delivered have enhanced the process of searching and applying for funding. It’s especially rewarding to reach low-income students and those who are the first in their families to seek a higher education.”

With more than 30 years of experience, SolutionsIQ has a deep understanding of software delivery excellence. The company’s broad range of consulting and training services are essential to any Agile project or transformation, and gives customers the tools and collaboration they need to succeed. SolutionsIQ is uniquely equipped to help organizations leverage modern Agile project management and software development methods to deliver solutions more reliably, with less risk and at lower cost.

More information about this initiative and theWashBoard.org is available at the Seattle Times. SolutionsIQ’s case study about the project is available on the company’s Web site.

About the Washington Scholarship Coalition

The Washington Scholarship Coalition is a public/private collaboration among foundations, state government, financial aid experts, and higher education professionals, established to improve access to higher education for students in Washington State. The Coalition seeks to ensure more students apply for scholarships; that the process of finding scholarships is made significantly simpler, more effective, and more engaging; and that data about both the supply of and demand for scholarship dollars becomes better understood.

About SolutionsIQ

SolutionsIQ is a leading provider of Agile consulting and training. The company offers a full array of technical consulting, software delivery, and talent acquisition services that together form a complete software development solution. For more than thirty years, SolutionsIQ has combined a hands-on approach with deep technical expertise to serve clients that range from the early stage startup to the Fortune 500.