Scrum Masters: "This Isn't What I Expected"

 

robert woods | agile coach/trainer
aarons, inc.

Paul was sitting in the middle chair of the conference table. On the left were the product developers and lead architects. To his right were the UI specialists, Sr. BA and quality analysts. In front of him, a very incensed Product Owner. As the Product Owner pounded his fist on the planning table claiming lack of results, instant messages furiously flew onto the screen of his open laptop from team members wondering why he is allowing this barrage of insults to continue. Paul's one thought was...

"I dont recall this being part of Scrum Master certification."

Whether Paul felt it was lack of training, lack of knowledge or lack of preparedness, he knew something was lacking!

ScrumAlliance.org has a definition of what a Scrum Master is and their role. You see phrases like "understanding of the Scrum framework", sounds good, "helps the product owner understand how to create and maintain the product backlog", no problem, "remove impediments to the team’s progress", got it, "facilitate meetings and always acts as a coach for the Scrum team, helping it execute the Scrum process", perfect....sign me up!

So, what's Paul's issue then?

Unfortunately, organizations attempting to make an Agile transformation make the mistake of assigning this role to team leads, command and control style PM's or staff managers without taking the time to understand all of the in's and out's (or nuances) of the more impactful aspects of the role.

With that in mind, many mature Agile adopters have evolved to defining this role as much more of a team facilitator (I've heard the title "Team Steward" used) as opposed to Scrum Master (by the way, what do you call them if you are using Kanban? WIP-Limit-Samurai!?).

The truth is, skillsets such as conflict resolution, keen observation, identifying individual communication styles, creating rapport and motivational techniques are all equally as important (sometimes more so) than helping someone increase their velocity or groom\prioritize a backlog. My father has been a software implementation manager for a large ERP system development firm for many years and one of his first nuggets of advice he gave me on successful "project management" is that it was 80% people and 20% process. This is no less true for team facilitators.

Scrum Alliance has it right in that this person has to be an evangelist for the Agile mindset and in the case of a Scrum Master, Scrum best practice. But what we're seeing is that the role is being asked to do much, much more. In the Practical Agile workshops I teach, I specifically rotate the responsibility of the Scrum Master amongst different team members. After each sprint I ask if they thought it felt like a full-time job. Inevitably the answer is Yes! Not only that, many say they dont want the job! Conversely, there are a select few who embrace the role; even find that it suits their personality so much that they leave the workshop with the professional goal of grooming themselves into that facilitator and in turn a servant leader of their team. I call this the "Diamond in the Rough" scenario. You simply can't have enough servant leaders who actually embrace the struggles, conflicts, understanding and humility it takes to place the team above self and make it their goal to help others achieve their own successes.

For those of you who fall into this category...I salute you. The world is a better place with you in it.

Either way, not having the right person in that role or giving that person the tools to be successful at it, can have adverse effects on the team and its success. I often liken these teams to a dogsled team, with the facilitator being the harness tying everyone together. The harness gets no credit, is rarely noticed, but if not there the team scatters, product goes no where and ultimately no success is seen. Imagine if it was a weak harness, unbalanced, not fitted right.

Please, dont minimize this role by drawing names out of a hat. For Paul? Perhaps this is not the professional arena he would choose to embrace (understatement). There is nothing wrong with that! It takes a brave person to say "yyeeaahh....this isn't for me." Hopefully we dont place anyone in that position to begin with.

Agile Mindset - Secure Delivery

Agile Mindset - Secure Delivery

Practicing great security, while deploying at the speed of Agility!

Robert Woods - Aarons, Inc.

Big brother is watching…and he’s not happy.

Once again, the kiddos have created a mess and big brother was left to not only clean it up, but take it on the chin for time to market. Looks like he had to play the role of “bad guy” and take the fun out of Agile delivery by throwing that whole ‘was it developed securely’ question out there and halting production deployment, skewing project deliverables and sending it back to development.

Who hired these guys anyway?

I recently attended the Agile2013 conference in Nashville, TN and it was brought to light by more than a few attendees what felt like a glaring absence of security awareness and discussion in the Agile community. Subsequently, I hosted a volunteer 15 minute lightning session on Agile Secure Delivery and sure enough, companies such as McAfee, John Deer and others showed as eager participants. I brought that idea back to Aarons (who happens to have one of the best Information Assurance teams in the Southeast) and they confirmed that, based on their experience, Security consistently gets a bad rep in software development circles; especially so by teams who claim to be “Agile”. Corporations want to be quick to market, generate feedback, and increase velocity; sometimes at the unfortunate expense of best security practice.

So is the life of an InfoSec or Information Assurance team who has the gall to live in our Agile world.

An ongoing (and concerning) trend is being seen with Agile teams failing to ensure all of the proper individuals are involved with the evolution of the product from the beginning and InfoSec is certainly no exception. They are often brought in towards the end of development to run penetration tests, and the like, and then find themselves having to explain why the product “doesn’t quite meet best practice security standards”; placing the Business in the unenviable position of weighing security risk with time to market. Hence the perception of security as a ‘production bottleneck’ is created and the legend lives on. Conversely, Agile teams create a Clint Eastwood reputation for development style; lacking any sense of structure or standards.

Here’s a question…Can we call ourselves Agile if we fail to adapt to the requirements of one of our key stakeholders? Because that’s what Security is; A Key Stakeholder!

In working with the Aarons Information Assurance team in constructing their S-SDLC (Secure-Software Development Life Cycle) we evaluated the Agile framework at the portfolio level. In considering our security team as a stakeholder in each solution we deliver, we specifically planned for security steps and checks baked into the Product Backlog itself. The degree of security involvement would be based on the degree of information risk associated with the product solution itself as determined by the IA team. In some cases involvement was minimal, in other cases they should be kept involved almost daily!

Now, what that means for the team, specifically the Product Owner, is the need to get Information Assurance involved from the very beginning of the product evolutionary process to provide that evaluation. They can then take the results found and work with their IA team on creating real user stories based on security requirements and regular code checkpoints. For example:

“As user A, I need to answer a series of personal questions, so that the system can verify my identity.” (Basic Security Feature Requirement)

Or

“As user B, I need penetration tests run against the code so that any potential weaknesses are identified” (Regularly scheduled and planned security verification)

The team , in turn, can estimate and plan for those stories which means they will need to collaborate in greater detail with the story stakeholder; Information Assurance! They recognize upfront this will be a part of their overall velocity. The exposure to best practice secure development generated from these conversations creates a culture of visibility into overall greater security awareness in developers, testers and business owners. In creating checkpoints, the team literally has multiple opportunities, pre-scheduled, where the IA team will help do what amounts to a secure code hardening.

I recently heard Gene Kim, Co-author of “The Phoenix Project” (great read if you get the chance), speak on continuous deployment and information security impact. He spoke of companies taking this concept to the next level by literally checking every line of code via automation as the developer hits SAVE. While this level of checks and balances may not be immediately feasible for many development shops, this does give you an idea of the direction some companies have headed to ensure not only quality security but also faster time to market by reducing the perceived security bottleneck.

For Agile teams not capable of that type of constant check, the point is, as opposed to waiting for the end of a project to see if we have it right, we will check security iteratively and often (sound familiar?)

The greater the exposure the team has to security best practice, the less time it actually takes to evaluate these environments. Eventually, the team gets in into a cadence of checks and balances which, in the end, expedites time to market with high levels of security as key product features.

Below is an example of a scaled framework we use for implementing security touch points baked into a product lifecycle:

 

As you can see, it’s a relatively non-evasive process that simply adds our Information Assurance team as an additional stakeholder with requirements no different than features needed from our users. The blue security shields are simply touch points baked into portfolio planning, backlog creation, Sprint 0 analysis, sprint planning, retrospective and release planning (this type of involvement might be typical for high levels of involvement based on initial evaluation of product).  The key point to remember is that this is a framework. Each product is different and this secure framework is Agile and therefore adaptive to the needs of each individual solution.

Speaking of which, shouldn’t great security automatically be considered core product features?

This Agile Security Awareness mindset can, and should, apply to any aspect of solution development we undertake as Agile teams. If we aren’t baking security into our backlog, we aren’t accurately capturing the needs of our user.

As an Agile team, that’s heresy! 

Conversely, wouldn’t you rather have a team who plans for the user’s needs, concerns themselves with corporate data security, while working with and aligning themselves with all required stakeholders in order to deliver quickly to market…securely?

And Big Brother…well I'm sure we can find plenty of other things to blame him for.

  

Robert Woods

Agile Trainer/Coach/Speaker

Aarons, Inc.