Scrum is a terrific set of ideas for getting work done of any kind. It’s mostly used as one set of concepts in the Agile Software Development way of thinking! Here at Passageways, I introduced Agile several years ago as a way for us to better react to changing needs amongst customers and being able to nimbly address those needs rapidly, without compromising code quality and stability.

So part of our process is the idea of a scrum meeting. The origin of this comes from rugby and describes a situation in which the entire team interlocks their arms and attempts to move a ball in a single direction forward. This analogy works well for team-based projects where teams are trying to move the project in a common direction.

When teams get to be more than 2 people, there is a communication need that arises that if not done correctly can result in team members doing work that is not relevant and may eventually be thrown out because team members misinterpreted something or were not in sync with other team members. This can be very costly to the project, and in the case of software development, very expensive with developers being some of the most expensive resources in a software company.

The scrum meeting is designed to provide the team a scheduled forum in which to sync up quickly and keep things from going too far off the deep end. The basic idea is that the team decides on a specific time every day to meet. Generally, this is the first meeting of the day so possibly 8 or 9 a.m. Some general rules for the meeting format are outlined below:

Rules for a Scrum Meeting

• Should take place at the same time each day
• Timeboxed at 15 minutes maximum
• Every team member stands (no sitting allowed)
• Nothing is discussed, only answers to 3 questions are given (discussions and follow-up happen after the scrum finishes)
• Each team member answers the following 3 questions
• What I did yesterday
• What I plan to do today
• What obstacles are preventing me from doing my work

Keeping the meeting at 15 minutes ensures everyone listens and only answers their questions. The “why” for discrepancies is answered after the scrum meeting breaks up.

Alleviating Obstacles

Generally each team has a team lead or project lead. It is this person’s responsibility to listen to each member’s obstacles and then after the scrum finishes, to remove those obstacles. The primary role of the project lead is to remove obstacles so the team members can do their work and move the ball forward!

The idea of having this very informal scrum meeting each morning seems like a fun exercise but not one that will be productive….at first. Try it, you’ll be surprised how much more in sync your team becomes after doing this every single day throughout the project. Again, scrums are not status update meetings, but rather are sync-up and report meetings. Your team members will remain focused and will always be aware of what others are working on. That ball will move towards its goal faster and if you are the project lead, you’ll look amazing! Plus your team will like the experience and appreciate being kept in sync too!

Other Scrum Resources

http://www.controlchaos.com/

http://en.wikipedia.org/wiki/Scrum_(development)

http://www.scrumalliance.org/

So this year, we once again made the Inc 5000 list! I was surprised to hear this but excited at the same time! Last year was our first entrance into this list and we made it into the Top 500 overall and Top 30 for Software Nationwide! That really excited us! Since the ranking are based on growth rates over several years, it’s very difficult to maintain high rates year after year so the list changes often and it’s common for companies to simply fall off the list right away. In a year like this, even though we’ve been doing well, I simply didn’t think we’d be on the list still, but there we ended up.

Focusing on high growth rates is something that is naturally somewhat foreign to software developers, but also built deep into our blood as well. Most developers focused on architecture of systems embed scalable ideas into everything they do. At Passageways for example, one of the earliest decisions I made was to separate the installation and deployment of our software from the development of it. So, we wrote an update system that would take care of deploying updates to any portal out there regardless of how many we had. This allowed us as a company to focus our dollars on scaling out the sales team and support staff and keep the developers busy writing new products and upgrading current versions of products. By allowing sales to focus on developing new markets and deploy large amounts of new products to a virtually unlimited market relative to where we were at the time 6 years ago, this was awesome.

There are so many new initiatives at Passageways, it’s great to see growth still be a center of what we do. I can only hope that our continued focus on the sales and partnership side and our incredible customer base will help continue to grow this very unique and interesting company!

http://www.lafayette-online.com/business/2009/08/inc-mag-2-prp-companies/

Over the last 6 years of leading the product development group of a successful software business, I’ve learned that every few years the group needs to take a look at their software factory and make some deep changes. At Passageways, we discovered several years ago that ago that our platform had much more potential than the add-on modules we were able to market. Many customers often requested add-on modules that we simply didn’t have time in our team schedule to do. While the platform does ship with a PDK, and many of our customers do use it, sometimes their developers simply don’t have the time or the organization itself just doesn’t have developers at all but are still willing to pay for the add-on module. So, Passageways introduced the idea of a consulting arm to help address these requests and it was immensely successful! Very quickly we learned though that building custom solutions for customers, sometimes very large solutions, and then selling multiple copies can confuse the market and our own staff as to what is a product and what is not.

At Passageways, we also began to reach a point where the number of enhancement requests and ideas was simply too much for the teams to handle in a reasonable period of time and we had to begin making tough choices and prioritize our work! For a small team of excited individuals, this can be more challenging than you might think! The realization that we simply can’t do it all and we may have to tell someone “no” is a very difficult thing for anyone running a business!

As you continue to grow, you also realize that your development teams have to keep up with the ever-changing technology marketplace and need to attend seminars and workshops so they are aware of what our industry is doing and can apply new technologies to the products they are creating.

So, there were a multitude of things happening all at once for us. So, I decided it was time to pump some energy-juice into our group and for the first time in our history, attempt to resolve every major problem area facing our development group today.

It’s important that developers feel like they are clear on what is expected of them, excited at trying new technologies, understand the focus of the business and its long-term strategy, and ultimately enjoy what they do day-to-day. It’s equally important that the rest of the company be clear on the progress development teams are making, what projects they are working on, and when to expect bugs and enhancements to be addressed, even if the answer is “we can’t get to that anytime soon”.

And so begins Project Rock and Roll….an attempt to make our software machine so focused on our business goals and really begin to once again knock the market out of the park! So far it’s been immensely successful and has not yet launched but stayed tuned as the launch approaches in the next few weeks!