Software development delivery is an expensive, time-consuming and risky proposition in even the best of circumstances. As the scope and complexity of projects grow, especially in large organizations, the chances for successful outcomes drop sharply.

It’s hardly a wonder that many disillusioned software developers opt for the greener pastures of start-up companies, which have amassed track records for applying novel approaches to produce systems that successfully support the needs of dynamic, evolving businesses.

How have the startups established these reputations? And how might their successes relate to your participation in technology efforts – as a business executive, a stakeholder or even as a technology manager?

Consider how frustrating it can be to wait months for the delivery of a new piece of software, only to be told at or near the due date that the delivery is delayed – perhaps for an unknown amount of time. Can you conceivably trust new delivery date estimates after that happens a few times? It seems unlikely. Trust erodes, and once broken it’s hard to re-establish trust in any organization.


While on a recent visit to Hawaii I was fortunate to be able to go stand-up paddle-boarding one day. After plenty of dunks in the ocean, I successfully gained my balance on the long board and was able to go about a mile from my starting point. Along the way I passed many other paddle-boarders and people in kayaks and canoes. Those points of reference alongside in the water gave me a clear sense of progress as I paddled. But when I circled back to return, I was no longer near any other boaters or paddlers. More or less alone on the flat plane of the ocean, I had no sense of how far or fast I was moving as I paddled along. I could see land in the distance move by slowly – almost agonizingly so.

Managing a large software development project can give a perspective similar to that return paddle-boarding trek. Without substantial interim sign-posts and deliverables, a technology manager or executive can feel an ocean of distance between his or her team’s current position and the ultimate deliverable destination. It helps when large projects can be broken into achievable chunks, but unless those chunks relate consistently to the changing needs of business, the tech team can lose its ability to convey to business partners where things stand, why delays happen and when they’ll hit the finish line.

Many large organizations have begun to adopt fresh ways to overcome these kinds of issues. One of the most talked-about approaches is a class of non-traditional methods called “agile,” which includes processes with such intriguing names as “Scrum,” “pair programming” and even “extreme programming.”

Even so, most companies face significant hurdles in making the transition to create productive in-house agile development processes. Key among the many required steps is aligning expectations and direct participation of business stakeholders. While the technical tools and processes themselves require changes from technology teams — often including vendors — it is quite common for business contributors and leaders to misunderstand the crucial roles they must play. Setting that foundation properly for the business functions and specific personalities involved can dramatically reduce software development risk, enhance organizational cohesion, build trust and lead to successful system delivery. In other words, as powerful as this set of approaches can be, nothing comes for free! There are some specific “must-dos” to pay attention to. Let’s take a look.

One of the more common agile methodologies, called Scrum, relies on a series of defined intervals for delivering working software, with each interval called a sprint. A sprint is commonly designated as a four-week span of time – sometimes slightly more, sometimes less. During a sprint the software development team will focus on a specific set of capabilities to deliver, all of which are defined at the start of the sprint. For example, some deliverables might be “mock ups,” which will allow for feedback and refinement before additional effort is applied. Another sprint deliverable might require that small tech and business task forces determine how best to phase a series of development tasks for a larger deliverable within a subsequent sprint. Still other deliverables might consist of fully functioning, fully tested software ready for live deployment for internal users or even customers.

A sprint is different from other types of software development efforts for several reasons. At the start of every one-month sprint the combined set of business stakeholders (including product management, marketing and customer service, for example) meet in a single session with the technical team – including all software development participants – to explain in detail what the business needs. The tech team responds in as close to real time as possible with a breakdown of each part of the coding and testing effort that will be required to deliver each component. Often, the team will use a point system to specify how much of a person’s time will be required to complete each task. Points are totaled for all requested tasks, leading to inevitable “horse-trading” among the business participants so that the joint team can effectively balance and prioritize the needs of the business with required technical underpinnings, eliminating as many surprises as possible. This step creates a crucial degree of cross-team communication that exposes many otherwise hidden elements that can slow or stall a software development project.

On every day of the sprint, all developers involved in the effort stand together to individually describe their prior day’s progress, their current task focus and any obstacles they have encountered. This daily meeting is known as the Scrum, which is where this agile development approach derives its name. During the Scrum sessions, developers also discuss how the elapsed time for each task has compared with the task points estimated at the start of the sprint. That step helps the entire team become better at estimating their work as each sprint leads into the next.

And importantly for these daily Scrum sessions, all business stakeholders – from the most junior-level participants to the CEO – are invited to silently observe any or all of the Scrum sessions, which normally don’t exceed 15 minutes in length. In this way, problems don’t stay hidden for long. In addition, a cohesive, trusting relationship can begin to develop among business and technical partners at all levels that aims quickly to remove obstacles that arise and allow everyone to focus on (and root for) timely and successful sprint completion.

At the end of the sprint, all deliverables are explained and demonstrated – with no exceptions normally allowed. For example, if something went awry along the way, it should also be described during the sprint demo session in order to create a common understanding of what is needed for the next sprint.

A number of excellent books and online resources exist for business and technical staff and management to learn about agile development, including Scrum. For now, I’ll conclude with a few must-dos that every large organization should strongly consider in making the transition to agile development, particularly Scrum.

  1. Scrum is not a process only for the technology organization. Yes, the tech team supplies and plays many key roles in executing a sprint, but the continued dedication and support of business stakeholders will make or break the success of each sprint.
  2. Business stakeholder must-dos: Drop any pretense that delivery failures are the fault of technology people. You’re all in this together. Be prepared to rationally justify the relative priorities of key business requirements, and be prepared to make tough calls about what must be included in each sprint and what can wait.
  3. Technology participant must-dos: Don’t view your business counterparts as the “enemy,” or any variation thereof. Realize that you’re there to help meet strategic and tactical business imperatives, ultimately to satisfy the customers who fund everyone’s paychecks. Dig in and learn more about the business side, why stated priorities are important. Learn to listen! And learn to explain technology considerations in plain English (or the everyday tongue of your organization).
  4. Senior and executive management also have roles to play, particularly in setting strategy, then reviewing the results that flow from each sprint, encouraging and insisting on cooperation and continual improvement – from both business and technology players – and insisting on clear evidence that the process is working, especially by attending the demos at the end of each sprint to see progress first-hand (and to help the teams celebrate their victories).
  5. When using Scrum, it’s essential to dedicate a “Scrum master” to orchestrate the stages of each sprint and the daily standup Scrum meetings. The most effective kind of Scrum master is a well-organized project manager with the focus and discipline of a strict nun. Although a certain amount of flexibility helps, so does a determination to meet delivery dates.
  6. Use the end-of-sprint demos to encourage the team. And then throw a party after every sprint. The team has earned it!

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access