DevOps team role and functions

Quote on this page: “we will not explain to you that we live on separated islands, we will not build bridges between these islands. We will explain to you that we live on the same island. Sea level rises. And it is time to act, together”.


DevOps team, functions and roles

Product Owner


1. Creates and MAINTAINS the Product Backlog. I emphasize MAINTAINS as this is an on-going job and more than likely a full-time activity. Nothing is constant in the world of software and it’s important that the Product Owner keeps his/her eye on the ball. Note: the Product Backlog must be refined prior to the Sprint Planning Meeting in order for the team to remain productive.


2. Prioritizes and sequences the Backlog according to business value or ROI (there are lots of tools to help Product Owners do this and lots of books on the subject) The Product Owner is required to have the Backlog sequenced prior to the Sprint Planning Meeting. This means that each user story must be ordered by relative importance. It’s no good to have 5 high priority or 5 medium priorities. It’s important to know which User story is #1, which is #2 etc.


3. Assists with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single sprint. User Stories are elaborated at the last responsible moment and it is the Product Owners responsibility to be there during the Sprint Planning meeting to help the teams to understand exactly what is required.


4. Conveys the Vision and Goals at the beginning of every Release and Sprint. The Product Owner must continuously remind the Team of the Sprint and Release goals. This helps to keep the team on track and serves as an over-arching yardstick for the team to measure their activity and progress against.


5. Represents the customer, interfaces and engages the customer. The Product Owner must continuously engage the customer and stakeholders to ensure the Team is building the right product and therefore delivering the ROI expected of it. The Product Owner has the opportunity to steer the team in a different direction at the end of every Sprint, so he/she must be ready to do just that if necessary.


6. Participates in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives. There’s always a lot going on and always an excuse to miss the meetings. But each of these Scrum ceremonies is another chance for the Product Owner to inspect and adapt. And as a result being present at these ceremonies is tantamount to success.


7. Inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done. Work that is either not complete or un-done needs to be re-prioritized or sequenced. An Agile PM is one who is quick to recognize and understand change and to ensure the Product Team adapts to the change in landscape, be it competition, target market or other.


8. Can change the course of the project at the end of every Sprint (30 days if you’re following traditional Scrum methodology by the book). The Product Owner is in complete control and can steer the team in a completely different direction at Sprint boundaries. And good Agile teams will welcome this change as long as the Product Owner is confident and knowledgeable.


9. Communicates status externally. The product owner is the voice of the Team to the outside world and should ensure that all channels of communications are open and that projects have the right amount of support required to succeed.


10. Terminates a Sprint if it is determined that a drastic change in direction is required e.g. a competitor releases a new version which demands a counter response. This is a pretty serious event for Scrum teams. And what this means “technically” is that all work done up until that point is lost. I have not seen this done to many times in my career especially since, there’s really not that much time between Sprints in any event.


The responsibilities of the Product Owner are onerous and there is no one else on the team to cover for him/her or pick up the slack. So if you’re choosing a Product Owner, choose wisely, the difference the difference can be success or failure for the entire project or, in the worst of circumstances, the success or failure of the company.

Please take care that your Product Owner is educated in his function. Get him/her on a Professional Scrum Product Owner (PSPO) training and certification. Use the Scrum.org certification.

At scrum.org you can find a register of all certified PSPO's.

Scrum Master

First question here is: is this a function or a role? There is no wrong answer. Can be both. I have seen both.


The Scrum Master does have the mindset of Servant Leader. Only a few Project Managers are able to step into this mindset change.


So what does a Servant Leader actually do?

Regardless of whether you call it a Scrum Master or not, this role brings with it the responsibilities of stewardship mentioned above. I've heard the role referred to as a Team Sherpa - appropriate, one would suppose, if the team uses BaseCamp. Anyhow, here is a checklist of key practices which the person fulfilling the role will need to demonstrate.


  • Shield the team from diversions and distractions
  • Facilitate planning sessions
  • Facilitate reviews and retrospectives
  • Coach the team in agile best practices
  • Help the team to collaborate better
  • Advocate the team's position
  • Anticipate
  • Find ways to remove team impediments
  • Make sure daily stand-ups happen, and are conducted properly
  • Encourage transparency and associated metrics
  • Understand and explain the team’s progress to interested stakeholders
  • Arbitrate between team members when necessary


Antipatterns of stewardship: What a Servant Leader doesn’t do

  • Direct the team by telling them what to do. Instead, he or she should assist the team to self-organize and do what it takes to expedite their progress
  • Manage the daily stand-up. A Scrum Master should simply ensure that the stand-up happens and is conducted properly.
  • Estimate the team’s work. If an agile team are using estimates in their planning, they must be responsible for them. The Scrum Master will arbitrate if needed.
  • Go off his or her own sweet way. A good Scrum Master will always maintain an awareness of where the team is in relation to its goals.

Please take care that your Scrum Master(s) is educated in his function/role. Get him/her on a Professional Scrum Master (PSM1) training and certification. Use the Scrum.org certification.

At scrum.org you can find a register of all certified PSM's.

DevOps Team
















In above you see segregation of duties. There no issue that an Operation engineer helps testing on any level.


If you get the full software development factory in place then more and more boundaries in segregation will disappear. Auditors looking for quality controlled promotion and the prober logging on that, not on who is doing this.

Role/Function

Development Engineer

Operations Engineer

Role

Developer

Functional Application Management

Role

Tester

Analyse

Role

Lead Developer

Lead Design

Role

(Technical) Analyse

Integrator



Tester

Role

PSM

PSM

There is also another a very important mindset change:

  • The DevOps team is responsible for the estimation of an Story
  • The DevOps team makes decisions if a Story should scissor in more parts and where that should that being done
  • It is the DevOps team who can decide that a story is not ready for sprint
  • It is the DevOps team who can decide that the user story is not clear enough to build


The Team will not take stories in the Sprint Backlog with an open end.

Important notice: stop doing resource management in a DevOps world.

Team evaluation is ok... max. once in 6 months, at least one a year.

Evaluate:

  • The maturity level of the team,
  • Maturity level on the roles,
  • The size of the team (minimum 3, maximum 9 team members),
  • Coverage ratio of all roles in the team (means also are all members capable to do more roles)
  • Continuous improvement
  • Use of Continuous Delivery tools
  • Outside code and test maturity check


All above in a coaching mindset.

please look at besite presentation. After 13 minutes they start talking about segregation of duties.

RIEKELT PASTERKAMP



Management Drives: Oranje / Geel

Copyright @ All Rights Reserved