Mastery, Autonomy, and Purpose in DevOps

In Daniel H. Pink’s book, Drive: The Surprising Truth About What Motivates Us, he discusses the motivations of knowledge workers. He makes the case that knowledge workers are driven by intrinsic factors and not the extrinsic factors of punishment and money. As he states, “Carrots & Sticks are so last Century. Drive says for 21^st century work, we need to upgrade to autonomy, mastery, and purpose.” A great video covering his work is viewable at https://youtu.be/u6XAPnuFjJc. For most research on extrinsic and intrinsic motivation start with the work of Edward Deci from the 1970s.

Here is an explanation of the three types of motivation:

Autonomy
This is the granting of control over their own work to those doing the work. Guidance is fine, but too much and it becomes the micro-management which can be detrimental to motivation. Valuable feedback, performance metrics, and boundaries can be all that is needed.

Mastery
This is an innate desire to get better at doing some task. If it is too easy, workers may get bored. If it is too hard and little progress is made, workers often get frustrated and give up. So tasks must be challenging, yet doable. And fostering an environment of continuous learning will add to motivation.

Purpose
This is tying the work to a cause larger than themselves. Workers, who believe in that cause, feel that there is importance to the outcome of the work beyond just their own accomplishment.

DevOps?
According to Wikipedia:

DevOps is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.

That certainly sounds like knowledge work to me. But are the three motivations the same for software developers and operations staff? And what might they be in a DevOps team. Let’s take a look in the chart below:

The management challenge then is to create a supportive culture where DevOps can flourish and the knowledge workers will be highly motivated by having aligned motivations of Autonomy, Mastery, and Purpose.

According to James P. Womack and Daniel T. Jones, “Lean Thinking is a business methodology which aims to provide a new way to think about how to organize human activities to deliver more benefits to society and value to individuals while eliminating waste.” In my opinion, Continuous Delivery and DevOps are the application of Lean Thinking to a part of the software development lifecycle. In particularly, the processes that occur from the planning of software development to deployment of the software into production.

But how do you know if you need Continuous Delivery and DevOps? Well, here are some typical candidates for applying Lean Thinking in your organization via Continuous Delivery (CD) and DevOps.

Long cycle time or lead time
A couple of lean metrics are important measures of the amount of time it takes to deliver value to the end user. One of them starts from the moment the feature is identified (lead time). The clock starts on the other when development of a feature begins (cycle time). DevOps is more applicable to the cycle time. If your organization has long cycle times, then CD and DevOps are a great approach to reveal where those delays are and start to eliminate them.

If your development team is using Scrum, then long cycle times may already be very transparent. The development team should quickly be completing high value features regularly. But that doesn’t mean those features are getting deployed quickly.

Mistakes during deployment
When deployments do occur in your organization, are you experiencing technical issues? Ever have a roll back? These mistakes can be the result of many different causes. Generally, they come about because of the large number of manual processes during deployment. Problems occur because of communication issues between teams and a lack of familiarity with the steps necessary to deploy. Does each deployment seem new every time?

Another symptom is an organization where there is a “hero mentality” regarding deployment. What I mean by this is that there is an expectation that there will be lots of problems during deployment and some individual or small team will rescue the deployments by putting in lots of late hours, consuming multiple cans of soda, and eating pizza. This mentality is often even more entrenched when a particular individual becomes the “go to” person (the hero) for the deployments because only they know or can figure out how to do them. Sometimes the hero team or individual embraces this role, but often times they really don’t want the stress and constraints that it entails.

Large overhead in deployment process
Usually, as a direct result of the bad deployments mentioned above, organizations start to place much heavier governance on the deployment processes in an attempt to prevent mistakes. This can be manifested via complex change control processes. Usually, these are manual and include a change control board and heavy documentation (readiness reviews, traceability, etc.). As a result, deployments are slowed down even more. Sometimes so much overhead can cause a rush to get things done at the end by those that do the deployments which leads to more issues. Also, because more people are involved with the communication of what needs to be done, there is further chances of errors occurring.

User impact from deployment
Does your organization take systems offline during deployments? How long are those downtimes? And once systems are brought back online do they need to learn a large new feature set? Downtime can often have a negative impact on your mission to your users and drives a lot of organizations to deploy very infrequently. But the infrequency of deployment means that a lot of changes to the system are introduced during those deployments. Impact to users can be substantial and takes away from the value you are delivering to them.

Resistance from operations staff
Are your operations teams resistant to perform deployments? Would they rather see systems never change and just support the status quo? If so, then it is probably due to the complaints directed toward them because of the issues described above. Often they have little control to resolve those issues and feel blindsided by what they are getting from the development teams. I can assure you that it is a rare individual who enjoys the stress of a deployment gone wrong. Clearly DevOps can help with this.

Assessment
Of course, there are other measurements and policies that can be used to assess if you need to make changes to a non-DevOps environment or even improvements in your DevOps environment. Do you have more ideas or want to know more about assessing your need for DevOps, Continuous Delivery, or Continuous Deployment? Leave a comment below or contact us.

As described by Jeff Sutherland, the Product Owner (PO) is “the person responsible for managing the Product Backlog so as to maximize the value of the project.  The Product Owner is responsible for representing the interests of everyone with a stake in the project.”

The Product Owner is a key role in the Scrum framework.  It’s a tough role, and people often have difficulty embracing it.  Today, I’ll discuss some of the common questions we get from POs in the government arena.

What’s my Role?
A Product Owner maximizes ROI by:

• Identifying product features
• Prioritizing features and other work
• Ensuring a steady flow of value by choosing the most important work for the next sprint
• Continually re-prioritizing, elaborating, and refining the list

A Product Owner guides and supports the team, keeping them from thrashing, by:

• Continually painting a picture of the destination (the vision and context)
• Ensuring a steady flow by “feeding” the team ready work
• Being available and actively interacting with the team on a daily basis to answer questions and provide guidance
• Making decisions to keep the team moving forward
• Providing a link between business stakeholders and the team
• Providing feedback as a sprint progresses
• Signing off on work results
• Providing a single voice to the team on product priorities and decisions

A Product Owner represents stakeholder interests by:

• Actively interacting with stakeholders to identify needs, gather information, and solicit feedback
• Ensuring the product creates value for stakeholders

What Skills do I need?
A Product Owner has, or develops, deep knowledge and competence in:

• Business domain and subject matter expertise (SME)
• Understanding and empathy with the customer, business, and market
• Weighing risks and making timely decisions with available information
• Conveying vision, setting context, and contributing to team and stakeholder understanding by “telling the story” of needs, behaviors, and success criteria
• Understanding and incorporating appropriate techniques to communicate with the team and stakeholders
• Understanding and use of conflict resolution techniques
• Understanding of group dynamics and complex change
• Negotiating priority and trade-off decisions
• Facilitating discussions and decisions
• Sensing and scanning inward, understanding and providing what the team needs to be effective
• Challenging the team to improve
• Sensing and scanning outward, understanding and delivering what stakeholders want/need
• Managing stakeholder expectations

What’s my Title?
“That which we call a rose, by any other name would smell as sweet” – Shakespeare

Scrum does not specify who should play the Product Owner role.  It only provides a general description of the role and responsibilities, and identifies a framework of ceremonies and artifacts that guide what to do.

So, the PO can be anybody (e.g., a Business Analyst, a Product Manager, or a Program Manager commonly play the PO role), as long as they have the necessary skills and time to dedicate to the role.  How they fulfill the responsibilities of the role will vary from person-to-person based on experience, need, and organization culture, structure, and constraints.

For smaller projects/product lines, with fewer teams, the PO responsibilities can be handled by one person (e.g., a product manager, senior business analyst, or program manager).

In larger organizations, or larger programs/product lines, the PO responsibilities are often divided because one person won’t necessarily have the skills or sufficient time to fulfill the needs of the role.

A common division occurs at the intersection of the “inward”, team-facing, tactical responsibilities (handled by a business analyst) and the “outward”, customer-facing, strategic responsibilities (handled by a Product Manager or Program Manager).  It’s important to remember that even if there is a division of labor and responsibilities, there will likely be some overlap and constant collaboration and “mind-melding” is required.  This maximizes transparency, minimizes hand-offs, and ensures congruent decision-making.   From the team’s point of view, there is still one PO, a “single voice” providing priority, information, and decisions.

Why is the PO role so hard to grasp?
Product Owner is a role, not a title.  A “job role” is a function that’s performed, a description of the part a person plays.   A “job title” is the name given to a position within a company, one that typically implies stature or hierarchy.

Traditional job titles have evolved over the years to align with specialized skills, collapsing roles, responsibilities, and skills into common titles (e.g., business analyst, project manager, and tester).  These tried-and-true titles have a long history, and are recognized, hired, measured, compensated, and rewarded similarly across the industry.  Many of us define ourselves by our job titles; they represent status and stability, identity and importance, achievement and acceptance.

Then along comes the Product Owner.  A new role with skills and responsibilities that not only don’t map cleanly to a job title we’re familiar with, but actually overlap several (e.g., product manager, program manager, project manager, business analyst).  Our axis shifts, our identity is challenged, and we sometimes find ourselves adrift in ambiguity.  To compensate, we grasp for a detailed description and firm boundaries to help provide clarity.

This is a common “shu” response when acquiring new knowledge, especially true when that knowledge comes with a significant shift from what we’re used to.   As we learn and become more comfortable, the need for boundaries lessens and our tolerance for ambiguity increases.   Mentoring and coaching can help support individuals through this uncertainty.

How is a government PO different?
The Product Owner role itself is not really any different in the government….the responsibilities are essentially the same, as are the skills required.

What makes the government setting unique is the combination and degree of:

• organization structure
• funding strategies and acquisition constraints
• compliance requirements
• technical complexity
• requirements complexity

I’ll talk briefly about how organization structure affects the PO role; the other factors are outside the scope of this blog.

Although the size and approach to government IT programs/projects is changing, at present they still tend to be on the large side.  The number of different agencies and/or vendors involved, the number of teams, and where work is performed are all factors in determining complexity of the program structure.

It’s typical for government agencies to rely heavily on vendors to “design-build-test” their solutions, and keep the requirements definition and user acceptance (UAT) in-house.   Subject matter expertise is split between government staff, who primarily have business domain knowledge and expertise, and vendor staff, who primarily have technical domain knowledge and expertise.

Since a key skill set for the PO is deep business domain expertise, it makes sense then for the PO to be from the government staff.  And since the PO is responsible for making scope, schedule, and budget trade-off decisions, the ideal candidate would again be from the government staff.  The government program manager is often a good choice as the PO, but care should be taken to adequately consider who is best positioned to handle challenges such as those identified below.

Typical, traditional government practices transfer risk and responsibility for failure to the vendor, but having the PO from the government staff means responsibility for successful delivery shifts to the government, as they can no longer claim to not be in the know.

PO Challenges in a Government setting
There are a number of common challenges that can impact establishing strong and effective Product Ownership of government projects and products.  The considerations listed here are not all unique to a government environment, but often occur at a higher rate.

Key considerations include:

• Time commitment – being a PO is a full-time commitment, not something that can be done “off the side of the desk”. Most of the considerations listed here affect the time commitment required by a PO.  Environments where all of these factors occur will significantly impact a PO’s productivity and effectiveness.
• Distance – remote teams increase a PO’s workload. This increase is often not considered when determining PO/team ratios.  There are tools that can help, but it just takes more time and effort to establish a rapport and communicate with teams and stakeholders who are physically remote from the PO.
• Hierarchical structures – power dynamics and hierarchical lines of authority can hamper a PO’s ability to make timely decisions.
• Frequently changing vendor teams – increase a PO’s workload, requiring more support to build intellectual knowledge and onboard teams.
• Multiple projects/products – one PO, one backlog, one team is a rule of thumb. That will vary somewhat depending on their maturity, the team’s maturity, and the type of work being done.
• Customer availability – PO’s need timely access to end-users and other customers/stakeholders to be effective. Generally, the less customer availability, the more PO time is required for coordination.
• Supportive environment – PO’s need support from leaders and sponsors to reinforce decision authority and help remove organization impediments.
• Acquisition constraints – PO’s in the government are sometimes also the COR (Contracting Officer Representatives). Their SME knowledge makes them a good choice for this, but increases their workload, especially during pre-award activities.
• Governance/Compliance – heavy compliance usually means a PO spends less time on CVA (customer value add) activities, and more time on BVA (business value add) activities.

So there you have it….leave a comment, I’d love to hear your thoughts!

As you many have read in my prior post about The Agile Impact regarding “Telework and Modified Schedules”, there are some variations on how moving to being Agile has impacts on the government agencies that are different than those seen in private industry.  In this blog, I will highlight some of the impacts that contracts and vendors have on the Agile transition in government agencies and outline some things to watch out for.

To set the stage, I first want to point out that we are not examining the contracting styles or types, but we are looking at how having most of the team members being outside of the agency, working for a vendor which is based on a contract, changes the landscape of how Agile is seen and implemented.

Before we get too far into the impact to the agencies, let’s set the stage a bit on what an Agile team really is: dedicated!  You can read more about the definition of an Agile team by reading another post: “The Reality of T.E.A.M”.  In short, an Agile team is formed with the intent of being dedicated to the team and to the solution they are delivering.  The team is intended to be created so that they remain a team, even after the release happens.  An Agile team is not created around their specialties, but more by pulling specialties together and having them work together to accomplish a goal.

Now that I’ve set the stage on what an Agile team is, let’s dive into the impact agile has on contracts and vendors…

In many government agencies, the teams that do the work building the solution are typically not government employees, but rather they are employees or contractors of a vendor that has won the contract.  These teams will sometimes be allowed to sit at the agency, but more often I’ve seen that they will be offsite, either at the vendor’s office or at their home.  This style of team poses a few issues when comparing to the definition of what an Agile team is.  Any ideas on what some may be?

When a contract is awarded to a vendor to build a solution, they usually go form a team to complete the contract.  In most cases, the vendor will assemble a team that has the skillset they need to complete the solution.  This team, which probably will not be sitting within the agency, needs to be able to communicate and collaborate with people within the agency on a daily basis.  This poses a number of issues since they are not co-located and most likely not on the same network.  It becomes a challenge for the team to be as effective as they can be; the team needs to work much harder to communicate and collaborate.  When this happens, communication and collaboration have a tendency to fall away and take a back seat to ‘just get it done’.

Also, when a vendor has their own team, which is not affiliated with any particular agency, the team in all likelihood has their own way of doing things and their own ‘set of rules’.  The team’s way of doing things may not align with the way that the agency does things, but they will need to find a way to work together.  If they don’t figure out how to work together, they will never really deliver the value requested.

Another hiccup in the vendor-agency relationship when moving toward Agile is the constant need for the agency to evaluate the team according to the contract.  While the vendor may understand the shift from a ‘contract-based’ relationship to one that is more ‘collaboration-based’ (see value 3 of the Agile Manifesto), they are still responsible for delivering the contract.  This puts the team, based at the vendor, in a bit of an interesting position: do they collaborate and deliver based on the communication/collaboration OR do they follow the letter of the contract and deliver based on that?  I’ve seen a couple instances, not many however, that manage to have both, but it really depends on how the contract is written and how the vendor’s relationship is maintained.

In most instances, the agency’s relationship with the vendor relies heavily on the contract and ensuring the things outlined in the contract are what are delivered.  However, the vendor and the agency can find ways to accomplish both – an Agile transition AND delivering to the contracted agreement.  The biggest thing they both need to keep in mind is that they need to communicate and collaborate in order to ensure both the value and contract are the drivers.

One of the easiest ways to ensure that both the transition and contract are met, is to have a vendor that understands and supports being Agile.  When a vendor is already aligned with the Agile values, it makes things much easier to ensure the communication and collaboration are the basis for the delivery.

Agencies around the government are beginning to see more and more of their employees teleworking and going to modified work weeks.  There are a number of employees that work enough so that they can modify their schedules to be off every other Friday or Monday, or even every Friday or Monday.  Due to a number of factors, many employees are also teleworking, or working from home.  Sound like you or someone you know?

What does this have to do with Agile?

I hear very often that one of the most talked about, and even controversial, things about an Agile transformation is the idea that teams must all be in the same room in order to satisfy the 6^th principle of the Agile Manifesto “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

If we take this principle into account, then we find that the telework and modified schedules turn this upside down and cause some confusion and concern on whether or not an agency can actually transition.  I have had a number of federal employees, especially leadership; ask if they can really transition to an Agile culture.  The actuality is “yes” – an agency in this situation, can most certainly transition to an Agile environment!

The biggest question for any agency is not “can we?”, but “how do we?”.  The agency needs to start with the understanding that the 6^th principle says that face-to-face is “the most efficient and effective…” way to communicate; it does NOT say that it is the only way to communicate.  It is so very important to encourage face-to-face communication for those that are in the office on a daily basis, but not so important that they relinquish the teleworking or modified schedules.

The key is to have the agency give the teams as much encouragement and support as they can to help create an atmosphere that fosters communication and collaboration in many different ways.  The agency will need to enable team members to communicate through means that may not have been ‘the usual’ in the agency.  Many government agencies have never had to put a lot of effort into ‘unusual’ modes of communication and collaboration because either the employees have been in the office all the time and/or the employees have worked fairly independently.  The more independently employees work, the less they need ways to communicate and collaborate outside of the ‘usual’ means of phone and email.

Agencies that need to step out of the ‘normal modes’ of communication are most likely very skittish of doing so for a multitude of reasons.  Some reasons I have been told that agencies may be skeptical is the level of security that needs to be maintained in the agency; most agencies will admit their security levels are much higher than those of private industry.  Because of the level of security that needs to be supported, many obvious communication mechanisms are overlooked or pushed aside without fully investigating the overall options.

However, in today’s technological age, there are many options that are available.  Any agency that is looking to transition to a more collaborative environment, one in which Agile can flourish, needs to look beyond names and find what works.  They should start by understanding the needs of the teams and work with the teams to find solutions, such as Office365, webcams, bridgelines, etc.

The one thing that agencies should never assume is that they cannot transition to an Agile environment simply due to these modified schedules or teleworking situations.  It all comes down to support and encouragement of teams made of people that are not all sitting in the same location…something that many agencies have not had to deal with before now!

Have you been in this situation?  Do you know some that are?  What do you, or they, think can be done to be more collaborative?

As discussed in the first post in this series Agile in the Federal Government – Going, Going, Gone Beyond Scrum, the history of Agile adoption in industry took the path of usage of Extreme Programming (XP) followed by the combination of Scrum and XP. In the government, the adoption of Scrum alone has become the de facto method of Agile adoption with the use of the term Agile and Scrum even becoming synonymous in some agencies. In our latest white paper we discuss why we believe the use of Agile Engineering Practices such as XP is crucial to the success of Scrum projects for the Federal government and that the government can again benefit by combining Scrum with XP as is already in use by industry. We believe this is because Agile Engineering Practices enhance the empirical process control (Inspection, Adaptation, and Transparency) of Scrum.

According to the latest State of Agile Survey by VersionOne, the top three XP techniques in practice are Continuous Integration, Test-First Programming, and Shared Code. What XP practices are you using at your agency? Is the use of them improving quality?

About a year ago, I co-authored with Bruce Yang a whitepaper entitled “Agile in the Federal Government – Moving Beyond Scrum.”  In that whitepaper, we predicted that the government would follow the lead of the private sector to adopt Agile solutions beyond Scrum to gain broader benefits.  Specifically, the private sector had learned that Scrum by itself would not effectively support scalability to replicate the success of one project across the entire organizational structure and adopted scaling frameworks such SAFe.  Similarly, it realized that the Scrum methodology was not necessarily appropriate for all types of work and looked for alternatives, most notably Kanban.

I am happy to report that the federal sector has in fact followed this anticipated pattern.  Some examples:

• DHS – Using SAFe at USCIS  to enable more rapid, high quality software delivery 

• DOL – “Why, yes, we Kanban” at DOL’s Office of the Solicitor 

• NGA –  SAFe becomes part of NGA’s School for Agile

• GSA – XP techniques adopted along with SAFe
  

We’re trying to compile a more comprehensive list of agencies that have adopted Agile techniques beyond Scrum and how well they have been working.   Would you mind sharing any non-confidential examples that you might be aware of?