~empowering clients to plan their tech projects with agility.

Bridging the Great Divide

A couple days ago, I was speaking with a friend of mine who works for one of the larger dev shops in the area. We were lamenting about the increasing gap between the development community and those we would serve. As we talked it became obvious to me that small shops and large shops, corporate clients or brand new start-ups are all suffering from the same malady; a miscommunication of expectations and realities when it comes to building custom software. As we talked, it became clear to me that empowering and expanding the education to the business/entrepreneur community, whether they choose to use us for development or not, is the best thing we can do to provide great service. Aside from writing excellent code, naturally.

I recall a sublime moment of serendipity when the value of my daily yoga practice was suddenly confirmed by the Wall Street Journal as a viable way to reduce stress and promote health. I was so stoked by this affirmation that I shared that article with nearly everyone I know! In my work life as a project manager, strategic planner and all-around analyst of things that involve people and processes, I can tell you I just as stoked when I first read the Agile Manifesto several years ago.

For those who may not know, there exists an Agile philosophy rooted in a series of guiding principles and a series of agile steps or methodology which help bring the principles into practice.

agile manifesto

The widespread emergence of this movement came about as software development teams learned to work collaboratively with each other and in dynamic communication with the client in response to the ever shifting sands of project scope. Anyone who has ever managed a hydra-like project with multiple stakeholders, producers and time constraints knows this one fact: things are fine right up until they aren’t. And then they can be horrible. And also that the end of the project is a moving target in software development that will have undergone significant changes before the final, tested version is launched. Working with the agile principles and methodology as our guide, development teams and clients are better able to address the inevitable changes that need to be made when building software project. I like to think of the team as being ninja-like its ability to deftly and confidently respond to changing project priorities, keeping the client in control and being mindful of the team’s resources. It’s brilliant, really and I am in love with it.

Over time I have observed that one of the most difficult things for a client in search of a development team, is that the development process is cloaked in mystery and jargon. Taking on a whole new philosophy (Agile) that comes complete with its own vernacular can be daunting. When tens of thousands of dollars and, sometimes, the very solvency of the company is on the line, this is not a time when an business owner wants to feel out of their depth. This is a dangerous paradigm where clients can feel overwhelmed, unprepared and unempowered as they enter into the world of software development. This can, and does, lead to faulty communication, panicky decision making and worse, handing the whole thing to the dev-team and hoping for the best.

The thing is, business people who need tech development may not possess a passion for learning to be software developers. They just want to effectively, happily and profitably run their business. Whether they make tortillas or sell tours to the Greek Islands, they want their tech project to come to life and to work for their mission. They want to engage with their customers, solve their problem and net a return. But in the world of software development where agile philosophy is incorporated, in part or in its entirety, their participation is implicitly required. As daunting as this can be, the only worse scenario is one in which these clients never get oriented to the process and don’t engage in the hands-on aspects of building their vision. This can be a nerve-wracking proposition to many if it doesn’t push custom development out of reach for some business owners altogether.

There is a growing gap that must be bridged to keep all the stakeholders in the “win” column. I think of this gap the Big Divide; or the space between the generation of that awesome software idea and getting that idea into the hands of a development team to manifest it. Not successfully getting over this divide can result in large losses of time, interested users, partners, money and motivation. The Bottom of the Big Divide is the resting place for many a project that was started and never finished or finished and never launched or launched but never succeeded – often due to a lack of pre-project planning.

To address what we are seeing as a dire need, we recently offered a hands-on agile project planning workshop. The participants spent a full day working through some basic steps of agile project planning, learning some basic terminology like Scrum, User Roles, User Stories, Story Points, MVP and Velocity. At the end of the day they came away with mind maps and simplified product concepts. We worked to develop an actual project plan using traditional agile methods including user roles and user stories and the process of prioritizing these stories into what would be their baseline minimally viable product (MVP). We spent time collaborating to estimate the difficulty of each story and the time it would take to develop.

At the end of the day everyone had a good understanding of HOW to prepare a project to issue an RFP (request for proposal), to talk to a financing partner or to a development shop. At the end of the day, everyone had a better grasp of the language and process used in software development, a project plan, an outline and estimate plus a handful of free tools they can use as they come up with new project ideas to plan.

I recently read that 68% of IT projects fail. This number is shocking to me when I think of all that wasted effort, money and time. To avoid having projects fall short of their goals and end up at the bottom of the Divide in a jumble of broken promises and blame, it is vital that we offer education and support to business communities on some basics of software development. Can we save all the projects? Maybe not. But if our goal is to help bridge the Big Divide and create great products for happy customers, it seems that we may have hit a the nail on the head by extending ourselves to reach our clients where they are. We can offer tools and information that empower business owners to mindfully, collaboratively and with great agility, take on that great tech idea and make it happen.