integration and implementation of technology-focused business solutions

November 2017

Why we use an agile-scrum approach for software development

November 21st, 2017

In the IT world, there are many projects that are too large and complex to be successfully managed in one piece with a defined single point of completion. Once the industry realized this in the early 2000s, the process of agile development was born. Agile development is about ongoing delivery and continual improvement of software, rather than that single end point of one large project. It also helps break down large projects into smaller, more manageable steps.

At LSG Solutions, we have been using an agile software development approach for more than a decade. We take a large project and break it into smaller pieces with primary units that last about one month, which are known as a sprint. So instead of running a marathon, we’re running a series of shorter sprints to accomplish the goal.

Every project is different, so the number of sprints will vary. All tasks for all projects are put into a sprint backlog, which means it’s waiting to be assigned and worked into a specific sprint. We’re continually adding things to the sprint backlog and then working them into sprints, which makes it a constant work in progress that stimulates both the mind and the technology. We use a specific software (Atlassian Agile Jira) to manage the assignments and organize them into sprints.

Scrum, which often goes hand-in-hand with agile, is an iterative approach. Each month-long sprint involves a day or two of planning and approximating effort. Each day has a short meeting to discuss progress and impediments. And at the end of each sprint, we reflect on lessons learned.

The scrum approach identifies the people who are actively involved in a task and those who are committed to or accountable for that task. Three specific roles are assigned: scrum master, product owner, and team member. The scrum master runs interference and acts as coach throughout the process. The product owner is the staff person or group who will be using the software system, which means IT doesn’t own the system in this accountability model. And the team members are the developers and subject matter experts who will be working on the project.

Product owners are involved extensively in determining the order that pieces should be worked, or the prioritization of smaller pieces as opposed to working on large pieces with little visibility. They are also in charge of the entire product backlog, although the team is involved in setting expectations as to what can be accomplished in each sprint.

With large pieces broken down into smaller pieces and assigned to different team members, it’s much easier to measure progress on a large project. When we complete estimates each month during sprint planning, we’re estimating those smaller pieces that can be measured along the way.

With each sprint, we have clearly defined goals for delivering increments of software. We use this process because it helps our clients have visibility into the software production process as opposed to waiting and wondering about their project’s status.

Comments: None

Reflecting on the days of pre-agile-scrum software development

November 7th, 2017

Long before agile software development started to mature, LSG leader Alan Sheppard recognized that there were significant challenges in the way things were done. Organizations struggled to create and manage a product when trying to balance the software developers’ approach, the business expectations, and the conservative risk managers’ requirements. Too many people couldn’t see eye to eye on how to approach and address the engineering of a large mission-critical product.

Some software developers had shiny object syndrome and never finished what they started, despite starting many tasks. Other developers could not adapt to the varied skills of their peers.

Some business owners or leaders just wanted it done, regardless of whether or not “done” was feasible. Others in the business world truly never knew what they really wanted done, and the right visionary people were too high up to get involved.

Some wanted every pre-defined feature and/or requirement available plus all sorts of new requirements. Those new requirement requests typically came as a result of developers explaining a perceived bigger, better, cooler way to do something.

In the midst of all these different expectations and approaches, the key end users often worried that the system would no longer be funded after the initial go-live, so everything would have to be rolled into one opportunity. Back then, the mindset of having multiple, ongoing opportunities didn’t exist.

Most expected the design phase to be a one-time start-stop effort, yet parts were moving all over the place during the entire project.

Then there were issues with accountability where stakeholders would blame the software developers if anything went wrong instead of focusing on measuring progress and quality. And if something went wrong, software developers would blame the end users for miscommunication about the requirements.

As the project continued, tensions would rise in the development team due to irrational constraints from a list of hopes and wants that conflicted with hard deadlines and limited funding.

Back in the late ’90s and early 2000s, IT software projects took big hits due to poor poor project management and software development processes. People in the industry learned many extreme lessons, yet some of these same obstacles still have to be addressed today.

LSG has been pro-agile and pro-scrum development since 2007, and we work closely with all of our clients to create clear expectations and efficient implementation of software development projects.

Comments: None


501 E. 15th St., Suite 200B
Edmond, OK 73013