The two companies merged about 7 years ago. Each company had a particular niche in the market that they served. The management team from both sides realized that the nature of the software they sold was complimentary. The customers of one product would need the other. Additionally, there were some economies of scale that would be realized once the companies merged. So, that’s what they did.
The honeymoon period didn’t last too long. Once the newness of the merger wore off and people started realizing the amount of effort that would be involved to get these two companies integrated, tensions began to rise. Systems needed to be integrated that ranged from timesheets to accounting systems. More importantly and even more challenging were the cultures that had to be integrated. These two companies had been run two very different ways and this was making the merger and integration even that much more complicated and painful. And then you had the software development teams…
These were two successful teams in their own right. Each team worked well within their own ranks, but once you put them together it was like trying to mix oil and water. Month after month would drag on with little to no progress on moving the products forward or into new markets. Something had to be done.
Finally, somebody stepped up to the plate and said anything and everything related to software development across these two companies would have to run through her first. She was taking charge. Despite the initial pushback from one of the teams they began to appreciate her fairness, objectivity, and her desire to get good and usable software out the door.
She also brought with her a relatively new concept of managing software development called Scrum. Scrum was one of the agile software development methodologies that were arising in defiance of the staid and outdated methods from the past that were no longer working. A transition was being made from methodologies such as the Waterfall method and into self-learning, more adaptive and flexible methodologies such as scrum.
That did the trick from the software development perspective. It started bringing the teams together and allowed them to work closer with each other. It started bringing the business together and allowed the right things to be worked on. It started delivering functionality early and often that the client could start using immediately while the rest of the application was being worked on. While the other departments in the company were still figuring out how to work together, this new way of running software development projects really did the trick for a long time.
That’s right. It worked for a long time. But, over time…the strength that made it work so well in this complicated and merging environment also began to surface as a weakness. Let’s talk about this strength and weakness and THE pro and THE con of scrum.
The PRO of Scrum – Its Flexibility
The main benefit of using scrum for software development is its flexibility. The very nature of scrum is designed to inspect and adapt. Small, bite-size chunks of functionality and development work called ‘stories’ are defined and selected to work on in short, iterative, and self-contained bursts of development. This affords an incredible amount of flexibility for a number of reasons:
- Feedback comes in fast and furious – At the end of each short development cycle (called a sprint) the team shows everyone what has been accomplished and is now ready for their feedback. The feedback will come back about what they like, what didn’t work quite the way they expected, and input on some other areas that may need attention based upon the changing needs of the business. This feedback is then reviewed and, if appropriate, included in the next short sprint.
- You Don’t Get Too Far off the Correct Path – Other development methodologies can allow months and months to pass before anything is ever at the point of being reviewed or demoed. The primary focus in the early stages of non-agile methods concentrates on documentation and lots of it. By the time functionality of the software is demoed, market conditions and business needs could have changed so drastically that the initial solution that seemed like the right thing to do is now way off the correct path.In scrum, there are really not phases in the conventional sense of software development. There is not a lot of upfront design, paperwork, and forms to be filled out never to be looked at again. Rather, it focuses on development and getting usable software to the internal or external customer. This allows the software to not get too far off the beaten path or become irrelevant as a solution.
- The scrum team selects what they will work on – There is a prioritized list of functionality that is assembled by the product owner on the scrum team. The team has the flexibility of choosing which areas of functionality they will work on next that will be included in the next sprint. The date of the completion of the sprint doesn’t change, however, what functionality makes it into the next release of software may change depending upon the work that was able to be accomplished.
An obvious upside of scrum is its flexibility. The amount of immediate feedback and the ability for the team to turn on a dime really makes this methodology great for many software companies.
The CON of Scrum – Its Flexibility
One of the drawbacks from scrum is, yes, its flexibility. The very quality that makes scrum so appealing to use is also the one area that needs to be monitored very closely from a business perspective.
Here’s the scenario. The company that uses scrum sells a software application that many clients use. The sales people and project managers at a company are responsible for interfacing with these customers that purchase this software. There are constant requests that come in from these customers for enhancements and improvements.
These items are prioritized by the product owner on the scrum team and included on a cumulative list of items to be worked on by the team called a product backlog. The scrum team will then pick the items that make it into the next development cycle and add these to the sprint backlog. It is this sprint backlog that includes the new features and functionality that will be included in the next release of software.
The clients want to know what is going to be included in this upcoming release. You provide them with a high-level overview of the sprint backlog so they have an idea of what will be coming down the pipe. The scrum team begins working and find out that they run into technical issues with a piece of functionality that takes longer to figure out than they had planned. This means something gets bumped out of the sprint backlog and opens up a potentially uncomfortable conversation with a client depending upon how critical the functionality is in their eyes.
That’s part of the challenge. It is the team that makes the final decisions on what will be included and what will not be included in the next release. At times this decision may come across as arbitrary or not rooted in what is important in the bigger picture of the application within the eyes of the customers.
True, this is a problem that surfaces with most development methodologies. It just feels that due to the iterative and frequent number of releases with scrum that this conversation has to be had on a regular basis. Does scrum work? Absolutely! It has brought peace and averted many contentious and disastrous situations using outdated methodologies. Just be aware of the fact that it has the potential for being a two edged sword and you’ll be pleased with the results.