Devops and Agile aren’t for you. Success variables to Devops and Agile adoption.
An increase in agile adoption results in a number of case studies with successful stories and failure or unclear results. We chose to look at DevOps and agile together are they complement each. Moreover, they have similarities, they are both inherent in lean methodology. Software processes have been gaining attention thanks to the market demand for solutions raising challenges of getting the product onto the market. However, it is not all types of organizations that are participating and aiming to meet these market demands for software products, meaning that some organizations can live without agile and DevOps. Then the question is, which organizations need agile and DevOps? All industries are affected directly and indirectly by technological trends, requiring organizations to position themselves well. Positioning the organization well might mean adopting agile or DevOps or both even and have a new way of working. This article assesses the agile methodology and the DevOps framework and their success factors. Because these are inherent to the lean methodology, we will discuss lean concepts. We also clear misunderstanding around the agile methodology and the DevOps framework.
First, we discuss agile, particularly scrum agile. Secondly, we then discuss DevOps and how agile and DevOps relates to lean principles. The third item is how the agile methodology can be integrated with DevOps framework. We then bring it all together and conclude with recommendations.
Agile is referred as being light weight. This comes from a comparison with the traditional waterfall methodology. Its quality of being light weight is also a factor to some of the misunderstanding of the methodology. Agile aims at satisfying the customer and maintaining that satisfaction through iterative prototyping. We discuss agile scrum, however, there are more flavors of agile such as extreme programming feature-drive, and more. Additionally, to customer satisfaction, agile methodology empowers teams. The bottom line benefit is the ability to do more in as short space of time. This drives innovation, faster respond to market expectations. Agile results in numerous practical benefits, especially when practiced well, and that is key. Following are aspects that agile impacts.
Handovers — The delivery team is responsible for the solution throughout its development to production. Handovers are prevented, the delivery team builds, deploy and support the solution.
you build it you run it (Amazon’s CTO)
Management Knowledge — It aids to have managers with technical skills and knowledge. Thanks to the nature and structure of agile managers can acquire these skills. For instance, at Airbnb, you first have to be a successful code contributor for six months.
Mentality — Agile team has a ‘can do’ mentality. No complaints nor emphasis on problems, instead the team think about solutions and reasons why something is possible.
“He who says he can and he who says he can’t are both usually right” ― Confucius
Talent — Best talent is considered. Additional to technical skills, attitude, communication and soft skill are important. Furthermore, cultural fit and ability to take responsibility are key models to assess when recruiting.
“A-players hire A-players. But B-players hire C-players.” — Steve Jobs
Decision Making — Decisions are made based on data. Nature of agile makes the best solution evident. No Hi.P.P.Os: Highest Paid Person Opinions.
Product Development — We get the product into the hands of a customer asap, allowing us to obtain feedback, measure effect, and iterate to discover a better solution. Big business goals are broken to small shippable business goals delivered per iterate.
From impacted aspects mentioned above, the possible benefits are endless. However, I can stress it enough that best practice and well implantation is key to drawing out these benefits. People scream asking for the agile they were promised, shaming and cursing agile. Question is, which agile are you implementing? Half agile isn’t agile you have to go full blown. Some organizations implement scrum thinking is agile. No! you’re doing it wrong.
Scrum is a method, agile is a mindset.
Scrum extends agile. Moreover, scrum process is can be described in more details and the guide narrows how to implement. For instance, it recommends time box, one to two week, it dictates ceremonies — meeting and what is to be discussed in those meeting. Agile values as per the agile manifesto are embedded in the scrum values. Agile values the following
· Individuals and interactions over processes and tools
· Working software over comprehensive documentation
· Customer collaboration over contract negotiation
· Responding to change over following a plan
This doesn’t mean only the items on the left are valued, for instance, individuals, interactions, process and tools are value. However, people and interactions are valued slightly more than processes and tools.
These are pivotal to the success of scrum Agile adoption.
The introduction of Agile in any organization is a powerful catalyst for significant change. For software development teams, this change requires a fundamental shift in what we have come to know as “best practice” for software development.
The Scrum Master must have the courage to protect and guide the team.
The Product Owner must have the courage to trust the team with the Sprint Backlog. He or she must trust that the team will deliver.
The team must have the courage to commit to as much work as possible within a sprint. However, the team must also have the courage to speak up when they think the Product Owner is asking them to overcommit — with due respect, of course.
Agile will not work if courage is not a core value in a team.
Transparency and openness are pivotal to empiricism. Participants in an agile delivery process must be willing to share everything.
The Scrum Master must encourage and coach the team to be open at all times. Openness builds trust in a team.
The limits and boundaries of the Scrum Roles need to be respected by all. Everyone on a project being delivered using the framework needs to be aware that
• the Product owner is in charge of what the team works on but not how they do their work
• the Team is responsible for getting the work done but not questioning what work gets done
• the Scrum Master and Product Owner needs to know that they are equal members of the team and not the team’s manager.
The whole Scrum Framework is a commitment to a new way of thinking.
• the Team commits to what they will do each Sprint by choosing the Sprint Backlog
• the Team commits to doing whatever is necessary in order to meet their goals.
• the Scrum Master commits to actively guide the Team and helping them adhere to the framework.
• the Scrum Master also commits to remove impediments that put sprint goals at risk.
• the Product Owner commits to a prioritized Product Backlog ready each Sprint
The Team must be focused to deliver the sprint goals. They must be protected from external distractions by the Scrum Master.
The Product Owner contributes toward the focus by ensuring that the Product Backlog is always prioritized.
Scrum Roles & Responsibilities
Scrum teams are self-organizing and cross-functional to optimize flexibility, creativity, and productivity. They choose how best to accomplish their work, rather than being directed by others outside the team. They must also have all competencies needed to accomplish the work without depending on others not part of the team. This is why business is seen as part of the Scrum team on a project. Scrum teams deliver software iteratively and incrementally, ensuring a potentially useful version of working software is always available.
Note to scrum masters.
A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves. (Lao Tzu)
The roles may differ per project. Projects are not the same.
The BA and Business Representative
It is recommended to have an individual as PO. However, in the BA can act as a PO. The BA focus is to advise the business on their processes and guides rest of the deliver regards requirements and quality assurance.
• The Product Owner is responsible for maximizing the value of the product and the work of the delivery team. He / She is the sole person responsible for managing the Product Backlog, which entails: Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the delivery team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what team will work on next; and,
• Ensuring the delivery team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have a Business Analyst in the delivery team do it. However, the Product Owner remains accountable.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the delivery team to work from a different set of requirements, and the delivery team isn’t allowed to act on what anyone else says.
The Delivery Team
The delivery team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the delivery team create the Increment.
Delivery teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the team’s overall efficiency and effectiveness.
The reinsurance delivery team have the following characteristics:
• They are self-organizing. No one (not even the Scrum Master) tells the team how to turn Product Backlog into Increments of potentially releasable functionality;
• Delivery teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
• Individual delivery team members may have specialized skills and areas of focus, but accountability belongs to the delivery team as a whole;
• Scrum recognizes no titles for Delivery Team members regardless of the work being performed by the person; there are no exceptions to this rule;
The Scrum Master
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
Scrum Master Service to the Product Owner
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.
Scrum Master Service to the Delivery Team
• Coaching the Delivery Team in self-organization and cross-functionality;
• Helping the Delivery Team to create high-value products;
• Removing impediments to the Delivery Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Delivery Team in organizational environments in which Scrum is not yet fully adopted and understood.
Scrum Master Service to the Organization
The Scrum Master serves the organization in several ways, including:
• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
Events or ceremonies during a sprint create the opportunity for the effective and efficient sharing of information. Each scrum event has a specific purpose, inputs and outputs, frequency and rhythm.
Most critics comments on agile as “nothing new” and that is simply because agile inherits a handful from the lean approach. Lean goes way back, developed and first implemented by Toyota (manufacturing automobiles) just after world war 2, under the leadership of Taiichi Ohno (1912–1990). Also, in the 1990s, the aerospace industry adopted the approach. This approach is about delivering the right thing, at the right time and place on the first attempt whilst reducing Muda. Muda is simply an activity that consumes resources without adding value to the overall process, in other words, waste. Muda comes in many forms, could be frequently rectified mistakes, unnecessary movements, and delays.
Lean has 5 main concepts that translate to principles. Values — this is the value of the product to the client. Only the client knows what they would like. Value stream — series of actions for delivering value to the client. Flow — value adding steps. These steps are continuous. Pull — downstream process pulls from upstream processes, eliminating inventory between processes. Perfection — kaizen process.
The lean approach brings about continuous improvements. Some of the benefits are reduced cost, development period, effective and efficient use of resources. This process builds quality in while creating knowledge (Poppendieck, 2007). The challenges of removing muda are that muda must be identified and it isn’t always obvious.
the illustration above is a summary of common and different aspects of lean and agile. The lean team pulls items instead of pulling them in. items aren’t pushed and rushed, this maintains quality. There are no time-boxed sprints in lean. Lean time measure items in time not effort, time from clients request to when the client receives as requested. It is the duty of the scrum master to address impediments the team faces in the agile approach whereas the entire team is responsible for that in the lean approach. Lean has a board also, the Kanban board instead of scrum broad as illustrated below.
DevOps is a cultural shift. It is mainly for business-orientated solutions or service providers. It extends to how we collaborate, communicate, set of technology tools and how we used them. Devops bring lean and agile concepts into one, it brings developers closer to ops. It touches on out ITIL aspects, social psychology and culture, system thing and continuous improvements as shown below.
Integration of dev and ops contradicts system engineering, whereby dev and ops exist as distinct. System engineering is common in the waterfall approach. DevOps practices have 5 fundamentals, which are as follows: Cross-functional team and skills — development and quality integration by agile are extended further as functional and non-functional roles are integrated. Continuous delivery — frequent updates and releases. Continuous assessment — assessment of costs and infrastructure, development and release processes. Optimum utilization of tool set — using a tool to its full potential. Automate deployment pipeline — eliminate deployment friction.
DevOps brings about sharing of responsibilities and goal. It is no longer about developers wishing to release quickly, and operation guys trying to keep environment stable. Goals are commonly shared. Integrating dev and ops eliminate delays and loss of information during communication. It then becomes easy to deploy, not so risky anymore. No more blame game. No silos and isolation. Change is welcomed.
Through DevOps, the product is always ready for a release at any point throughout its cycle. It reduces the cost and uncertainty of going live. There are just enough feedback loops in this process. Enabling us to improve and keep clients happy. A happy client, and an approach such as this, means a healthy environment.
Agile and DevOps
Agile and DevOps are two of many branches of the new ways of working. This also shows that in order to get the best out of agile or DevOps, you have to couple it with other best practices. Just as a mean should be nutritionally balanced for your health sake, these practices must be implemented well together for the sake of the organization’s health.
Agile demands a certain culture for it to be successful. At the heart of the required culture is trust. Management trusts the delivery team to deliver the best solution. They also should have trust in themselves for having selected the right team. This allows the team to autonomously explore ideas and solutions freely. Failure isn’t an issue, instead, the team takes away knowledge from the experience encouraging them to keep pursuing.
Only by letting go of old habits and working methods, agility can be achieved. (J. Kamer)
Managers are expected to delegate decision-making authority and responsibility to the delivery team. The team will then do what they think is best for the organization and take ownership of that. Management communicates strategic goals and priorities, and the delivery team decides on how to deliver these goals.
Managers become servant leaders and will only work on tasks that teams cannot solve themselves. (J. Kamer)
We chose agile and DevOps together because together they cover the entire SDLC. Agile covers it well from initiation throughout to implementation, not so strong on operation and disposition. Devops strongly addresses the SDLC starting from development to disposition, it completes agile, a match made. DevOps and agile merge on development, integration and testing, and implementation. What we chose to take from DevOps into agile as a merge is automation. We automate our development environment and environment entities such as databases. Furthermore, we automate building, integration, and testing. Deployment is also automated, irrespective of the environment type (Dev, SIT, UAT or Prod). Moreover, DevOps enables and encourages feedback, which is key for all stages of the SDLC.
implementing scrum doesn’t make you agile.
Just one simple recommendation. Do it right, do it or don’t at all.
However, don’t get caught up trying to figure out the right way. Take Christianity, one bible and countless different churches with different beliefs. Now, forget about Christianity so that what I say may not be taken as an opinion or implication to Christianity. The agile manifesto serves as the bible thus can be interpreted and implemented differently. The truth is organizations and projects differ. Thus ones’ right way can be ones’ worst way, so find the agile way that works for you. However, the following must fall, the traditional military hierarchy management structure or agile won’t work for you. Break the silos. Encourage collaboration, and cross skills. Don’t fall into the micromanagement trap, lead. Keep the team motivated.
Daniel Pink defines three key ingredients for individual motivation:
· Autonomy: the desire to direct our own lives, aka not to be told what to do and how to do it
· Mastery: the urge to get better at something that matters
· Purpose: the yearning to do what we do in the service of something larger than ourselves.
Do you like the agile and DevOps combo? Thinking of implementing the combo? Well here are few items you would have to manage before they become challenges.
Management — educated them so that they may buy-in.
Keeping teams and meetings lean and efficient.
Change the teams or organizations view on the combo.
Establish a fail safe environment.
Now you are set, adopt, learn, revise, improve.
this combo is not for anyone but anyone willing to change. some people want change so bad but resist it so much. Pilot it if need be, and the team grows wings to carry the organizations up. Investing in people motivates them through these combo values and guide has promising rewards. It is important to do it right for yourself, how Barclays may be doing it successful might not work for you. It is worth identifying wasteful processes for improvements or elimination, and reparative processes to be automated.