Agile software development is a way of developing software that has surfaced over the past decade. It focuses on getting working software up and running above an incessant and unnecessary amount of up front planning and documentation that quickly becomes outdated.
One of the more popular methodologies of agile software development is a scrum. Scrum is a way that self-directed project teams can work in very short development cycles, receive immediate feedback from end users, and continually look for ways to improve the way they get things done.
There has been a considerable amount of information written about agile & scrum software development. But, what are some of the underlying values that are behind agile & scrum? The following is a list of four of these values:
Individuals and Interactions over Process and Tools
There are three things that are needed in any software development company to deliver their products. These three things are People, Process, and Technology. People are needed in order to get the work done. Processes must be in place in order to provide a path to follow (similar to an assembly line) for the work to be complete. Finally, Technology is what the people in the company will use to create the software that is being put together on the assembly line.
An interesting dynamic has surfaced in recent years that fly in the face of agile & scrum. Process and Technology have taken precedence over People. This has resulted in a “dumbing down” of decisions that are being made because everything is relegated to the realm of Process and Technology.
How does this play out in the real world? Let’s say there’s a problem that comes up on a particular project that needs to be solved. Somebody sends out an email to a group of people identifying the issue that just surfaced and the feeding frenzy begins
Emails start flying left and right. People start adding their own opinions as to why this problem surfaced or how it should have been taken care of earlier. Instant messages start popping up on everyone’s desktops casting all kinds of aspersions and negativity about the person that raised the issue. The list of the 7 original people that were on the initial email has not grown to about 15 because everyone feels compelled to cc: their manager and their manager’s manager. The thread gets ridiculous in size and there is now more confused than ever before.
Enter agile & scrum. Rather than an email being sent out to 7 people, an agile team member would get up and walk out of their cube and go to another agile team member and talk to them face-to-face. They would lay out the situation, provide all the nuances of what is happening and the concern about the impact that is going to have on the project. The second person may not have the immediate answer but they get with another team member, huddle up in a conference room for 30-minutes and get the problem resolved.
That’s People over Process or Technology. The same principle applies whether it’s management, a customer, another department or whoever else needs to provide input.
Working Software over Comprehensive Documentation
A criticism sometimes leveled against agile & scrum is the apparent lack of planning that is conducted and the documentation that is created. That’s really not the case as agile & scrum advocates planning being done all of the time and not just at the beginning of the project.
Documentation is going on all the time in an agile & scrum environment as well. It just appears in a different form than people are used to with other methodologies. There are stories, charts, product backlogs, acceptance tests, and the biggest piece of documentation of all…working software.
Rather than spending so much time up front on documentation that rarely gets used, agile & scrum teams use just enough documentation to get them through each sprint and through the next release of the software.
You can think about it in the context of how much water does it take to float a boat. Not much. Once there is enough water to get the boat floating, anything additional really isn’t necessary.
It’s the same concept with agile & scrum. Put just enough documentation in place to “float the boat”, but anything above and beyond that is really unnecessary and just consumes time that can be spent on better activities to get the next release complete.
Customer Collaboration over Contract Negotiation
Have you ever sat through a contract negotiation meeting on a software project that has gone bad? It’s not pretty. “We have a bona fide contract”, one side may say. “The contract doesn’t reflect reality,” the other side may immediately retort. The gap between what is in the contract and what reality quickly becomes miles apart. That’s no way to get a project done and a satisfied customer.
Agile & scrum focus more on customer collaboration over contract negotiation. The constant involvement of the customer throughout the software building process and iterative reviews allow the customer to see where the software solution is going and determine if that really meets their needs.
It’s up to them to change their mind on the functionality that the software delivers. If the software does not meet their needs of what they had in mind they have the ability to adjust in mid-course.
It’s up to you as a software development service provider to come up with a fair and profitable way for this collaboration to occur with your client. The best case scenario to enable this type of interaction is a time and materials based agreement. Otherwise, you may get locked into a fixed fee agreement. This could ultimately lead to your company losing money as the needs of the client change over time.
The bottom line and the spirit of the above-stated value are to give the client what they want. They want working software that helps solve their problem. Agile & scrum allow you to deliver it quickly and correctly.
Responding to Change over Following a Plan
The final value that is a big part of agile & scrum is that it embraces change rather than just blindly following a plan. Think about it this way…you go on a trip and you have your course all mapped out. You know exactly where you want to go and how you want to get there. Halfway through the trip, you notice that there is a river that you need to cross. There’s one problem, however. The bridge is out. That is a HUGE change to your plans. What do you do?
Follow the plan and plunge off the cliff into the depths of the murky water below? Of course not. You adjust your plans and find another way to get over the river.
This is the value that is inherent to agile & scrum that you need to be able to adapt to change rather than blindly follow a plan that was set in place months or possibly years before. Constantly inspect the current situation and adapt to your environment accordingly. Anything else will plunge you into the murky waters of software that just doesn’t meet what the client wants.
Even if you have not fully embraced the agile methodology in your company you can start following the principles above. Just having a different mindset and approach to your next project will yield big results.