Roles and Personas

Roles

There are many roles in Agile or DevOps teams, in our book we tackle a few roles and we use personas to understand from the user’s perspective the journey they are taking when using our software. Agent 77 (myself) and Agent 13 have different roles in our clients and organizations we coach and work for, there is not right or wrong answer. The only caution I would make you aware of is not mixing “Titles” with “Roles” and vice versa. Our roles can change depending on the context and way we are working, which we should be comfortable with. As we develop more skills in what we do and how we work (remember guided continuous improvement) we will feel safe and accustomed to working in potentially one or more roles in our teams, divisions and company.

“Let us frame the teams in my diagram. The development team stands for the typical teams I have been working with since the 80s. The feature team represents that same team working with a platter of cross-functional service roles enabling them to be accountable for and deliver continuous value (features) to their end-users.”

“I like Agents 13’s  list of roles and it shows the ability to scale while ensuring the right roles are in place to support DevOps. For our friends who are starting down the path of DevOps and who are a little shaky at working in an agile way we might start with smaller teams and have multiple roles. However I do not recommend a team without the following roles as a minimum:

  • The Product Owner
  • The Scrum Master*
  • Team Member – Developer*
  • Team Member – Data Architect*
  • Team Member – Tester*
  • The Architect Owner*

*These roles may be handled by more than one person.  Developer & Tester or Developer and Architect Owner. There may be times when you require an independent tester i.e. developing special software for healthcare or aviation. 

 Of course, every organisation and situation is different and that is why we need to be pragmatic, context counts!

Planning and creating feature teams are great and I suggest as your team and project scales you formalize roles like SRE, Release Manager they will make a huge difference  when you have larger projects and products. Some of these roles may be in your project team and dedicated, others needed when required. Working with smaller teams (of teams) allows you to manage scale while still providing reliable and excellent DevOps services.”

Personas

Typically, personas are fictional characters, representing users of your solution to convey user problems in their own context. Personas enable us to identify, be inspired by and develop deep empathy with real users.

Users may have different roles. For example, when you create a common engineering system you will have users who are using the system and users who are concerned with the acquisition, support, and maintenance of your system. In this case, you would identify and define two separate personas.

Step Notes
Understand your users
Build a connection, interact, and perform Gemba walks to walk the floor in their working environment to understand the value stream and its problems.

Keep them simple and relevant

Persona descriptions should be concise (one, not many goals), catchy, and up to date. Continuously revise as you learn.

Make them real

Use a name and picture that you and your team will recognize and empathise with.

Characterise your stories

Use your personas when defining scenarios, value streams, and stories. For example, <persona> wants <what> so that <why>.

Visualise

Make your personas visible to everyone involved in your solution. Hanging up posters in cubicles, collaboration areas, and main passages will help everyone familiarize themselves with your personas.

Personal Poster Example

CIO

Born 1965, San Antonio, Texas and lives in Dallas, Tx.
Mr. James, Ronald, Maverick holds a Bachelor of Science in Phycology at The University of Texas, San Antonio.

Mr. Maverick or JR as many call him is a “slick” but warm and friendly character in our upcoming book on the DevOps Mindset. Mr. Maverick cares about his IT team very much and could charm the socks off a Texas Longhorn. JR is liked by many in his organization; however, he is not as well trusted by the Overlords as he used to be. Mr. Maverick has a group of loyal staff, including Mr. Barker a bit of an opposite to JR. Of course, Mr. Barker would never call him JR; he would only call him Mr. Maverick because well, Mr. Maverick is his boss. Mr. Maverick has held many IT positions in the past, including starting as a Sales Professional for HP and IBM mini and mainframe computers. Over the years he has risen through the ranks to hold this senior position by delivering using high-paid consultants and Big name firms. He also received his promotion from outsourcing to a foreign country where he was able to reduce his IT spend significantly. Recently he has discovered (actually this was made painfully aware to him by the Overlords) that both the Offshore roadmap and use of external consultants was not giving him the value and velocity for his IT department, and he was probably paying more than he bargained for

So, after hearing a talk at a DevOps event by the Agents of Chaos, JR decided to enlist them to help with their digital transformation roadmap and help improve the value, focus and velocity of his department. However, MR. Maverick has a few ideas about agile and DevOps, something he has heard about for a while and read in various CIO magazines; he thinks of these as Marketing terms and something that can be bought. While Mr. Maverick has held on for many years to traditional IT ways of working he has come to the end of his tenure if he doesn’t do something fast and get DevOps working quickly as he has promised to the Overlords providing him with a little more rope to get the transformation completed more quickly as they view his IT department ageing, procrastinators who are not able to keep up with business demands. JR says in his mind, “I will get it done, they don’t call me Maverick for nothing!“