In the world of IT, as systems become more powerful and complex, managing these complex systems becomes easier and easier. A big part of what I have dubbed the IT revolution comes from a new group of revolutionaries pushing forward the message that serious does not need to be complex. In the world of agile development, we have been advised that agile does not mean fragile. Today I am going to zoom in to a little old thing called Scrum.

When Scrum was invented and first implemented, it was meant to be a simple framework with few roles, meetings, and artifacts. I now feel no choice but to ask, what in the world happened to the simplicity? As it has evolved, Scrum and agile project management in general have become polluted. I have even heard many agile scrum coaches proclaim that a ‘vanilla Scrum’ implementation will only work in small organizations with simple projects. Although this could be no further from the truth, I still feel the pain from teams who are suffering from being bitten on their Scrum-butts!

All too often, at the direction of someone in an agile management position, we abandon the simple things we know to be true. Whether it is done in an effort to find the holy grail of increased efficiency, or to make the adoption an easier to swallow pill, does that make it all right? Does simple with few rules, roles, and artifacts necessarily mean easy? Where do we draw the line? 

In this article, I intend to present why teams choose to struggle with something so simple. Let’s start by taking a walk down Scrum Lane and discussing some of the pieces that people struggle with most.

Roles
The first of three concepts we will discuss today is roles. I cannot help but notice that one of the largest questions organizations face as they transition to agile is "where does my role fit into the mix?" People are constantly trying to squeeze what they do into the agile mold, when in fact there are truly only three positions, regardless of agile methodology: Customer, Implementor, and Facilitator. In Scrum, the three roles are Product Owner, Scrum Master, and Team Member. Each role has been called a number of different names, but the simple truth is no matter what HR calls you or what is on your business card, you should fall into one of these three roles. If you do not, it may be time for you to do a serious introspective and identify how you can modify your role to fit better into one of the three identified.

Meetings
The second concept up for discussion is the correct Scrum meetings. Scrum was founded on the premise of three meetings. The first is the Daily Standup (or Daily Scrum). The daily meeting is a chance for the team to report their progress to each other! This is the perfect time for the team to use subtle pressure to ensure accountability for each individual. The meeting has only three questions for each individual to answer:

1)      What have you done since we last met?
2)      What are you planning to do until we meet again?
3)      Is there anything preventing you from completing the items you committed to? 

The meeting is capped at fifteen minutes in length. No problem-solving happens here. The team simply identifies issues and takes them offline to resolve. Attaining the right level of detail is the key to making this meeting successful. This meeting should happen in the same location at the same time, every day without exception.

The second meeting is Sprint Planning. The most common misconception is that no initial preparation takes place prior to this meeting, which is simply not true. Key considerations must be met to achieve success. The product backlog must be properly groomed and backlog items must be ready to be placed into a Sprint. An architectural runway must also be in place for the team to be able to successfully plan for the work. Many people forget these critical steps, and when this falls squarely on the team, the team fails. Effective Sprint planning largely contributes to a team’s success in adopting or implementing Scrum.

The team should meet at the beginning of the Sprint to review the work for the upcoming sprint and break the work down into small tasks and tests. This is a learned art and you should never expect a team to catch everything on the first pass. This meeting should be brief and time-boxed equivalent to one hour per week of your team’s sprint length. Four week sprint = four hour meeting. Proper execution in the Sprint Planning meeting is critical to the team’s success.

The third Scrum meeting is Sprint Review, which includes the demo and retrospective. Of all the Scrum meetings, this one can prove to be the most beneficial to the success of the team. The entire concept of inspection and adaptation rides on the premise that the key stakeholders will have a chance to review what the team has created and to provide instrumental feedback. This feedback is what helps the team stay focused on exceeding the stakeholder’s expectations and allows all key parties to be on the same page. The retrospective is the only opportunity that the team has to inspect and adapt the process. Although at times the meeting may turn toward evaluation of individuals on the team, it is critical to maintain focus on the process and look for ways to prepare an agenda that allows the team to stay focused on delivering meaningful results in the retrospective. The team will be grateful that you helped them stay on track.

Artifacts
The third and final concept to keep Scrum simple is focusing only on the three artifacts. The three Scrum artifacts are as follows:

1) Product Backlog – This should be a well-managed list of work to do in upcoming sprints. The work should be broken down in a manner that makes it easily consumable within a single sprint.
2) Sprint Backlog – This backlog should contain all of the small tasks & tests needed to complete a subset of work from the product backlog. This is the actual work that the team commits to deliver.
3) Burndown Chart – This visual indicator is a constant reminder of the work remaining to be completed as part of the sprint commitment.

I think too often we try to take this very basic framework and overcomplicate it to fit our organizational culture. If we get back to basics, and focus on keeping it simple, we will all re-discover that Scrum is a true flavor of agile project management and it really does work!

One question that I run across quite often is "What will agile development do for my organization?" What many people mistakenly do is equate agile project management with doing more work, with less documentation and fewer people. Although the premise is to get more done in a more favorable way, I have never met a team that could successfully implement agile principles without having to slow down first.

Agile project management has finally started to grow up and mature. On the heels of multiple training and coaching engagements, one thing I have learned is that agile has certainly made its way into enterprise level application development. Software development tools have evolved, and people have changed the end delivery method for getting things done. One constant that has held true throughout the test of time is the capability to work in an environment where everything is visible.

Many agile organizations struggle with the prospect that visibility and transparency may not help everyone see eye to eye. The fact is, even though agile, Scrum, XP and the like have all taken monumental steps toward enterprise level adoption, the key to organizational success remains establishing and maintaining a solid foundation. One core success factor remains the ability to retain transparency and keep focus on the ability to inspect and adapt. This is not intended to be confused with scope creep or gold plating.

In fact, one of the biggest hurdles I run into when agile starts to grow is the inability of the organization to learn from and accept the nature of what change has presented. Although from a business perspective we may all still see things a little bit differently, we need to learn how to keep our focus and learn from the error in our path. We need to take on the pressure of increased visibility and treat it as an opportunity for growth.

Whether our team is just passing through storming and beginning to norm, or just beginning to form and has not reached this monumental step, we need to teach people that it is better to see eye to eye, and that even though the road may not always be a primrose path, the path we take will continue to teach us to be the best we can be with regard to agile project management. Enterprise level agile adoption is not always an easy sell, but neither is any process that may require us to refocus and slow down a bit.

Let us each take a step back and a deep breath. Even though we may not be resolute in our belief that complete transparency will lead to enhanced process scenarios, we will quickly grow to understand that success relies on our ability to accept these core fundamentals.

• If quality in the current product or project is continuing to suffer and the teams are never reaching a point where the existing bug log is diminishing, they are suffering from growing technical debt.
• When developers are drained because the QA process takes far longer than it should, and the development team calls for a better process to handle testing, this is a sign that technical debt could be nearing a breaking point.
• When the product is nearing release and only the absolutely required test cases have been addressed, technical debt could be an issue.
• When the customer is enraged that the product does not perform in an expected manner, that also can be tied to increased technical debt.

1. Act NOW!
2. Identify key areas for repayment.
3. Enable testers.
4. Stop forward work as needed.
5. Make commitments and keep them.
6. Remain transparent.
7. Avoid additional debt at ALL cost!