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 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!)
- 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
- 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
- Increases Flexibility – agile reduces the upfront investment by creating a more efficient IT development process which helps maximizes return on investment (ROI)
- Reduces Risk and Increases Quality – agile provides users, managers and stakeholders with greater stakeholder visibility and more granular control
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.
Here is a summary of the stages
- 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
- 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
- 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.
Here are the DAD consortium has established four certification levels:
- Disciplined Agilist-White Belt(Shu)
- Disciplined Agilist-Yellow Belt(Shu)
- Disciplined Agilist-Green Belt(Ha)
- Disciplined Agilist-Black Belt (Ri)
For more details, here is a link to DAD certification philosophy
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.
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.
DevWorks Article describing a self-assessment survey: http://ibm.co/1zOMkqH
DevOps Survey: https://ibm.biz/BdRVGy
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
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. 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.
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.
 Core Scrum — Values and roles, http://www.scrumalliance.org/why-scrum/core-scrum-values-roles