I’ve worked with over 100 teams transitioning from waterfall or a modified iterative practice to Agile Scrum and Scrumban. I’ve seen a lot over the years. Usually people are excited to learn there is a better way to do business. A way that saves money, time, and the pain of rework, and one that allows customers to get exactly what they need, when they need it. But there are also those skeptics, generally those who fear change and/or those who have experienced the pain of a failed Agile implementation. This latter group is my ABSOLUTE FAVORITE to work with. Bet you didn’t expect that last statement! Let me explain why.
My affinity for working with the underdogs of an organization stem from my own underdog experiences. Those who seem to be the least likely to do great things are often the ones who have been overlooked for their skills and talents. I enjoy more than anything the ability to help bring those talents and skills to the forefront. Typically teams who experienced a failed Agile operation usually do so because of a member of influence led the operation through using Agile mythology, rather than Agile methodology. The 5 most common myths I’ve encountered throughout my career are as follows:
Agile is ad-hoc
This is simple. AGILE IS NOT AD-HOC. Agile is a process designed for flexibility. With flexibility being the operative word. Being flexible means being able to adjust quickly to changes. But it does not mean there is no constant.
Properly experiencing the flexibility an Agile practice offers, means to have a clear understanding of the end goal, and to systematically include changes within an agreed upon timeline. For example, if your project is following a 2-week sprint cadence, any new, high-priority features should be added to the backlog to be worked on next sprint; not the current sprint. The flexibility comes in to play by communicating between the customer and team that the highest-priority item which will be the first thing worked on in the next sprint. What I’ve seen in cases of misinformed teams and customers include, those who believe throwing new features to be worked on should be executed and completed immediately, within the current sprint. The problem with this approach is, a team will gain no traction, features may never be completed, and a customer with no clear vision in mind will never be satisfied. This is the quintessential project management triple constraint killer. A scenario like this will inevitably lead to scope creep, confusion, lack of quality, and frustrated personnel. All ingredients that make up a recipe for failure. Despite this myth, Agile does incorporate, both schedule planning and technical planning. A team that has dedicated even just one day towards a sprint commitment, will equal a minimum of two days of productivity lost. The cost of changing direction mid sprint is very high, as you have lost planning time, execution time, and the ability to meet the timeline agreed upon for the sprint.
This is a sure fire way your sprint will fail, your project is likely to fail, your customer will not be happy, and your Agile practice will crumble. Remember, Agile is not ad-hoc. It is iteratively planned with priority in mind.
Agile does not have documentation
The Agile manifesto dictates that the Agile methodology “promotes working software over documentation”. The operative word being “over”. That does not mean none. Documentation is here to stay. For a long while at least. In order for humans involved in the full-scope of the project to do their best work actively and to promote contingency planning when personnel is replaced, new users are added, and new features are produced, documentation is necessary. What this line in the manifesto really means is that it is more important for your product to be operable and up to standard, than for your documents to be overly robust and redundant. Documentation is a necessary evil of the industry, and in order for the product to be effective throughout the lifecycle, certain documentation is necessary. A backlog for example. It’s pretty important to know what the requirements are for the product you’re building. Another important factor is the RTM, requirements traceability matrix. Knowing who requested the feature, what the feature is, and whether it was proven to operate as expected, is pretty important too. If you ever have to backtrack or CYA, you always know whom to discuss concerns with. User Guides, although rapidly shifting in how they are provided, is another important piece of documentation. Excellent quality software is user friendly software, however, even the best, easiest, programs need documentation that help users navigate their way around.
An example of useless documentation is pretty much anything that doesn’t help you understand how to build, test, release, roll-back, and use the product you’re building. And especially anything that promotes redundantly stating what you’ve written in other, more useful documents.
You must follow Agile by the book
Agile Evangelists, our favorite group of Agile experts, can be zealots about the process. And rightfully so. It’s actually an amazing way to do business. For everyone who is passionate about Agile, their reasons may vary.
My passion for this process stems from the humanism involved. As a former psychology major, I am VERY interested in people and how they operate and interact. Agile has its fair share of touchy-feely goodness and I’ve seen teams grow to become BFF’s due to the integrated communication required by the process. Being able to channel my inner psychologist, I’ve been able to support teams as they have gone from storming to norming to performing, very rapidly without expensive team building activities and frivolous trinkets. The mere act of maintaining consistent and open dialog has led fractured teams to become framilies away from home, or at least to be very comfortable producing together.
This considered, making sure every single aspect of the Agile process follows the prescribed framework does not make a project successful, nor does it congeal a team. Instead, implementing the elements that are suitable for your team and circumstances will. Example, if you are in the final stages of your project and the team will soon be moved on to complete work on other products, holding a Standup 2 or 3 times a week will not damage anything. Or having your Scrum Master serve a dual role as a technical writer, will not cause your team to self-destruct.
In general, the best Agile teams are those that have the autonomy to try different things and flex the process as appropriate to their needs. Sticking with this approach will typically ensure you have a happy team, customer, and high-quality product.
Project Manager (PM) and a Scrum Master (SM) are the same role
Project Managers and Scrum Masters are not the same role. They are different. For a quick synopsis on how they differ, check out this article written by yours truly. Otherwise, for a more personal and possibly painful explanation, keep reading.
The age-old argument that a PM and SM are essentially the same tends to be a topic of debate at every coaching engagement I’ve encountered. Often, new and ambitious Scrum Masters believe themselves to be managers of sorts, and Project Managers new to Agile tend to want to absorb the responsibilities of the Scrum Master. Some believe these two roles can be one-in-the-same, however, I beg to differ. These roles are very far apart on the spectrum as they have very different intentions and motivations.
Project Managers are in fact managers. Although PMI dictates conventional project management practices, these edicts are relevant no matter what execution methodology is in place.
And as a manager one is expected to make decisions. A manager spends his or her days deciding whom to hire, lay off, or fire, whom deserves a raise and for how much, who needs positive/constructive feedback, and which stakeholders to engage further or minimize interaction. PMs also manage the triple constraint ensuring cost, quality, and scope are well managed. The Scrum Master is devoid of such responsibilities, instead focusing on the team and their commitment to the Agile process.
The ideal Scrum Master on a team will perform the usual functions of the role, including facilitating the Agile ceremonies, but the major aspect of the SM role is to provide a safe environment among peers in which to build a self-organizing team. The Scrum Master does this by gaining the trust of the team, devoid of any decision making risks to the team members. This is accomplished largely within the most important ceremony in Agile Scrum, which is the Retrospective. This meeting is for the team to air grievances and celebrate wins. Typically, delivery personnel are more likely to be open and honest with peers than with superiors in the org chart. This lack of trust stems from the intrinsic nature of the hierarchy. A PM’s role is to make swift decisions. The Scrum Master, lacking such authority, is no threat to a team wishing to be heard. Having the ability to openly discuss concerns and give each other kudos is a crucial communication practice on any team and Agile creates the framework to make such connection easy. As long as the almighty powerful PM stays out of the way.
I have personally participated in projects where the PM insisted on being involved in the team’s activities and the results were dismal. Within a particular project, the PM sat in on the retrospective and proceeded to attempt to resolve a disagreement between two team members. Rather than the two members getting clear on the issue and resolving it between themselves with the rest of the team there for objective support, the PM created a messy argument that left everyone in extreme discomfort. Needless to say the PM was, in short, shunned from all further retrospectives; to the benefit of the team.
Need more proof? Let’s all enjoy a horror story starring me as an Agile leader doing things incorrectly. In 2015, I joined an existing team as a Program Manager overseeing a program with 3 disparate but dependent projects. As one project was already in flight, I recognized the disorder on the project immediately and implemented an Agile practice, consisting of 1-week sprints. This non-software development project held sprint planning, sprint review, retrospectives, and daily scrum ceremonies. During a sprint review meeting, I decided to participate with the intention of merely observing. My observing quickly became what was later called “a hostile takeover” by the PM in charge. In an attempt to manage quality and schedule, by rushing through the materials presented and giving intense critique on the content, I ended up causing confusion for the team members and frustration with my PM. I learned quickly that as a leader I needed to butt out of the process and let the Scrum Master (who reported to the PM on this team) handle the ceremonies and my direct reports should report up any pertinent information. Staying in my veritable lane, I learned to let my team members do what they do best and work continued without my running the show. Let’s just say, lesson learned.
Agile is ONLY for small-pansy-projects
Not sure if any project can be classified as “pansy”, however, Agile can be effective for nearly any sized project. This is done by implementing the very core of Agile into the organization of the project. That is, to break the project down into smaller groups and institute a scaled approach. The Scaled Agile Framework, also known as SAFe is the concept of applying Agile principles to a program or enterprise level operation. So if your organization has a variety of large scale programs with interconnected personnel or functionalities, a scaled agile approach could be right for you. For more information on SAFe, visit http://www.scaledagileframework.com/.
The best way to make sure you and your organization don’t fall victim to failure of agile implementation is to arm yourself with the knowledge needed to make an informed decision and an effective strategy for efficient and accurate implementation. Agile Coaching is a common service that allows experienced Agile practitioners to support your organization in transitioning to an effective agile-based practice. Through my trials and many many many errors, I have learned what works and importantly what doesn’t work for teams and companies. Contact me to find out more about how I can help you transition to Agile, improve your agile practice, or help keep your agile shop running smoothly.