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.