Ran across an interesting article on “Getting started with Ansible.” Good overview

Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs. It can be used for advanced tasks such as continuous deployments or zero downtime rolling updates. Ansible is a push-based configuration management tool; it means we can push configuration onto the node machine directly without having any central node. It communicates with remote machines over SSH.The main goals of Ansible are ease-of-use and simplicity.
Feature of Ansible
• Simple and Ease-of-use
• Agentless
• YAML Based Playbook

Here is the link to the actual article 

Advertisement

What is Agile … Really?

A I am constantly amazed at the misconceptions that most people have regarding what agile is and how it is used.  Often times when I bring up the topic of agile, people immediately start talking about “Scrum” and how they like it or not; or whether it can be used on big projects or not.

Agile is hard to pin down as it’s somewhat of a moving target so I have written this article to provide a short overview to those people interested in understanding what Agile really is.

Most people view “Scrum” as agile, and while sometimes a few people may mention concepts from “Lean” or “eXtreme Program” like Kanban boards, pair programming or test driven development, generally people think Scrum is agile.

However, agile is much bigger then Scrum. For example take a look at the diagram below.

Agile Frameworks

Agile really is about “delivery value by satisfying the customers needs by frequently delivering working software and quickly responding to change”.

Most agile teams welcome changing requirements if it helps the customer’s competitive advantage. And, by frequently, we mean from a couple of days to a couple of weeks using a face-to-face mean, as its often the most efficient and effective method of conveying information.

The key is most times, “the customer doesn’t know what they want”, so course of development ideas will flow which will cause customers to change their minds.  Therefore, if you want to deliver customer satisfaction you must respond to change.

In summary, here are four main benefits of agile, (if done correctly!)

  1. Delivers the Right Solution  – agile helps the team, users and other stakeholders to align with the right people to deliver the solution that the business actually needs
  2. Accelerates Delivery – agile shortens the development cycle and provides incremental value by using a set of short time-boxed iterations to get to the right solution faster
  3. Increases Flexibility – agile reduces the upfront investment by creating a more efficient IT development process which helps maximizes return on investment (ROI)
  4. Reduces Risk and Increases Quality – agile provides users, managers and stakeholders with greater stakeholder visibility and more granular control

What are the DAD Certification Levels

DAD Certification Levels

In adopting a Shuhari strategy for their certification program, the Disciplined Agile Consortium has established a program which allows an individual to achieve measurable and incremental success (belts) that can be achieved using an iterative approach to their learning and practical experience.

Shuhari

Here is a summary of the stages

  1. Shu (Learn) or beginning stage focuses on learning the basic techniques and philosophies of disciplined agile development. With a goal of achieving a White Belt and/or Yellow Belt
  2. Ha (Detach) or intermediate stage is represented by Green Belt certification and is based on seeking to understand the range of strategies available to you and when they are best applied
  3. Finally, Ri (Transcend) is the “master” stage, is represented by the Disciplined Agilist-Black Belt certification, is where you are consistently sharing your learning with others.

Summary

Here are the DAD consortium has established four certification levels:

  1. Disciplined Agilist-White Belt(Shu)
  2. Disciplined Agilist-Yellow Belt(Shu)
  3. Disciplined Agilist-Green Belt(Ha)
  4. Disciplined Agilist-Black Belt (Ri)

For more details, here is a link to DAD certification philosophy

IBM DevOps – Self Assessment survey

Reedy Feggins Jr

Recently read a good article on adopting “Continuous Delivery practices”. In the white paper, “Adopting IBM’s approach to continuous software delivery,” the author, Paul Bahr discussed IBM’s adoption framework for iteratively introducing new capabilities and planning improvements.

Capability Adoption Framework

In the  our-part blog series that outlined a good four-step process for getting started on your improvements journey (step 1, step 2, step 3 and step 4). The author also discussed that the first steps for planning your DevOps adoption was to take a 

For those organizations interested in baselining where they are with DevOps adoption. Here is an article describing a self-assessment survey you can take. http://ibm.co/1zOMkqH

Here is the link to the actual
IBM DevOps Practices Self Assessment survey.

Resources

DevWorks Article describing a self-assessment survey:  http://ibm.co/1zOMkqH

DevOps Survey:    https://ibm.biz/BdRVGy

View original post

IBM DevOps – Self Assessment survey

Recently read an update to an article on adopting “Continuous Delivery practices”. In the white paper, “Adopting IBM’s approach to continuous software delivery,” the author, Paul Bahr discussed IBM’s adoption framework for iteratively introducing new capabilities and planning improvements.

Capability Adoption Framework

In the  our-part blog series that outlined a good four-step process for getting started on your improvements journey (step 1, step 2, step 3 and step 4). The author also discussed that the first steps for planning your DevOps adoption was to take a

For those organizations interested in baselining where they are with DevOps adoption. Here is an article describing a self-assessment survey you can take. http://ibm.co/1zOMkqH

Here is the link to the actual
IBM DevOps Practices Self Assessment survey.

Resources

DevWorks Article describing a self-assessment survey:  http://ibm.co/1zOMkqH

DevOps Survey:    https://ibm.biz/BdRVGy

Scaling Agile Planning to Support Large Distributed Programs

Earlier this month during the 2014 IBM Innovate Conference, I delivered a 1-hour seminar on scaling agile planning to support large programs.  If you didn’t get to travel to Florida for the conference, here is the session material for you to review.

DAG-2333: Scaling Agile Planning to Support Large Distributed Programs

Many organizations have embraced agile practices such as only Scrum and eXtreme Programming (XP), only to discover that while these practices provide great benefit to individual development teams, they don’t always scale when used at the project or program levels.

In this session, we explore real-world challenges and discuss how some of organizations have used practices from other agile methodologies such as Disciplined Agile Delivery (DAD) and Scaled Agile Framework (SAFe), to successfully scale to these levels

 

 

 

 

Agile Delivery Model

Now let’s take a look at the Scrum framework. Scrum is the best known and most widely adopted agile framework in the world today.[1]  With its emphasis on delivery high quality solutions faster and continuous improvement, Scrum teams value commitment, openness, and respect.

Agile teams respond to change by focusing on the customer’s immediate needs and by not doing anything that is not required immediately.  The Product Owner, the person that best represents the customer, selects the stories (or feature) that provides most valuable to the customer, and the whole team works on that feature.

  RTC ALM for Scrum

 

Agile is about delivering software as soon as possible, and then regularly and frequently. Scrum teams focus on working on valuable tasks each day until the PO is satisfied.

Rapidly responding to change and delivering in short intervals is often the most challenging part of adopting agile for those people who have spent most of their careers working with a traditional or waterfall method.

In addition, agile is about enjoying your work. Agile team are self-organizing, meaning the team, and everyone on it, is empowerment to make decisions that would otherwise be made by the project manager.  For example agile teams estimate their own work, work with the PO to decide which stories are prioritized for delivery.

Finally, Agile is about using the knowledge, ideas, and inspiration of everyone in the company.  Agile teams take time out to reflect on the recent past and to identify ways removing blocks or impediments to producing high quality code.

[1] Core Scrum — Values and roles, http://www.scrumalliance.org/why-scrum/core-scrum-values-roles

RTC Adoption Problems: Tool, Education, or Perspective?

An excellent post on practical use of RTC and how it can successfully be adopted.

Best Practices for Building Software Platforms

I work with CLM customers a lot and sometimes I encounter people struggling to adopt RTC. Once in a while the problem is with RTC – a bug, the rare difficult-to-use feature, etc. Once in a while it’s just a technical knowledge thing. For example, if you’re not aware that your Websphere JVM heap space should be no more than half your physical memory, then you’re going to have issues.

And sometimes the problem is human nature. It’s our own difficulty with breaking out of an existing perspective, breaking old habits and old ways of looking at things. These are the most difficult problems to solve, but solving them provides the biggest payback.

Example: Scrum Iteration Planning

To illustrate this issue, let’s say you’re using the RTC Scrum process template. You think that it takes too long to load an iteration plan. You perceive a performance problem. Fair enough.

So…

View original post 1,073 more words

Scaling Agile – How Organizations are really doing it. Or Not…

Updated post based on presentation I delivered at recent 2014 IBM Innovate conference. Here is the link to the actual presentation, click here.

Agile Practices.   What is SAFe?

The Scaled Agile Framework® (pronounced SAFe™) is an interactive knowledge base for implementing agile practices at enterprise scale. SAFe provides organizations with a set of best practices, artifacts and suggested tooling necessary to scale agile from the team to program to the portfolio level. SAFe** aims to address some of the concern that many have had with other Agile methodologies such as Scrum when attempting to scale. Created by Dean Leffingwell, SAFe has been successfully adopted by a number of large organizations internationally, click link to some of their case studies

Over the last 4 or 5 years, I have had a fair bit of experience helping organizations scale agile, see blog post from 2011 on Scaling Agile – Why Scrum isn’t enough,
so have a good feel of how different approaches have worked for me personally. Last year I was invited to attend SAFe training by my company and obtained my certification as a SAFe Program Consultant certification.

Since then I have had several consulting engagements where I have had the opportunity to apply SAFe, along with other approach such as DAD in complex and distributed environments. So far using SAFe concepts has led to more successful engagements as it seems to seems to address a lot of the challenges that enterprise that I have had to work with face.

In my next couple of blog posts, I’d like to give a bit of an overview of the framework while also sharing some of my thoughts and experiences.

Introduction

The “Big Picture”**, shown below, provides a graphical representation the SAFe roles, teams, activities and artifacts necessary to scale agile from the team to the enterprise level.

022214_2335_ScalingAgil1.jpg

Portfolio Level

In the Scaled Agile Framework (SAFe), the Portfolio Level is the highest and most strategic layer where programs are aligned to the company’s business strategy and investment approach.

The PPM (Portfolio and Program Management) team works with the business to gather ideas to drive the Demand Management process. This process produces a set of Investment Themes (or business initiatives) that the enterprise will focus on over the preceding 6 to 18 months.

Here is a short list of some of the key concepts used by SAFe at the portfolio level.

Investment Themes represent the set of business initiatives that drive the enterprise’s investment in systems, products, applications, and services. These are often broken down into a set of business and architectural epics used to plan, execute and track the set of business to ensure the teams aligned with the overall business strategy.

Business and Architectural Epics a large-scale development initiatives used to realize the value of these investment themes. Each Epic captures the business priority, effort estimate (in story points), and expected value and can be further broken down into sub-epics or features as needed.

Kanban Systems is use to assist the PPM team with visualizing the flow of epic-level value along with allowing the organization ot define work-in-progress (WIP) limits to assure an effective flow and to help manage each initiative through to implementation.

Portfolio Vision defines how the enterprise’s business strategy will be achieved and usually requires the creation of a product road map to visually communicate how the different investment themes are being realized via business epics over time.

SAFe is not right for every organization. Some are too small, some are already invested in their own approach and some are not ready for agile at the enterprise level. Whether you follow SAFe or some other approach is not as important as applying lean and agile applying lean and agile thinking to help realize value across the organization. I have been doing this for years in my coaching practice and that is part of what drew us to SAFe. 

The goal for SAFe adoption as this level is to focus on delivering business value quickly. Agile should be about incremental business delivery not team iterations. The cornerstone for this is to have product portfolio management drive programs which drive the delivery of minimal business increments, click here to read more on this topic.

** Scaled Agile Framework and SAFe are trademarks of Leffingwell, LLC

——————————————-

In my upcoming blog posts plan on digging deeper into how organizations are executing their scaled agile transformation with SAFe at the portfolio and program levels. Will also share some of my experience architecting process and tooling solutions to support the various roles required to make these transformations successful

 

Scaling Agile – Why Scrum isn’t enough

Agile Best Practices – Scaling Best Practices for large organizations

While most teams can start using agile practices, such as Scrum and XP, they often run into hurtles when adoption is extended to other parts of the organization.

Most often these challenges (or agile scaling factors) severely limits it adoption.

Recently delivered a session at the Agile Brazil 2012 conference on why most larger teams often must scale Scrum to overcome challenges (such as geographical distribution, organizational change issues) in their environments to success use agile.

Here it the link to the actual presentation.

Presentation Summary

Agile is a highly collaborative approach to software development that focuses on producing high quality “working code” that is potentially shippable at regular intervals. While many aspects of agile are new and innovative, agile practices are derived from many other successful methodologies such as traditional SDLC, iterative development and lean.

Over the last 5 years adopting practices such as Scrum or XP for small collocated projects has become fairly straightforward but we have found that most teams run into problems as their projects move away from an ideal agile team (e.g., 7 +/- 2 people, co-located team, cross-functional skills, self motivated resources all sharing the same vision and drive to deliver potentially shippable code).

Scaling agile to support larger more complex projects and problems often requires strategies that address both the team’s and the organization’s challenges and perceptions with regards to agile practices.

This session focuses on some of the key agile practices that must be scaled to overcome these challenges. The session uses a number case studies illustrating approaches for adopting more disciplined agile practices. In addition we will also cover 2 or 3 specific agile practices that must be scaled.