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
Advertisements

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 – 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.

Succeeding with your First Agile Pilot Project – Lessons from the Trenches

In a follow up to an earlier post regarding, Succeeding with your First Agile Pilot Project, posted on February 19, 2012 by rfeggins, Have coached several additional teams over the last few months and wanted to share some addition lessons that seem common to most teams starting out.

Pilot

While not difficult, agile adoption does take some time to sink in. Often agile teams need 2 or 3 iterations to work though practices related to being self-organizing. Activities such as creating a properly groomed backlog, estimating and report progress all seem to take some time for most teams. Here is a typical timeline that has worked well for me in the past 

Typical Agile Pilot Timeline

 Consider that the teams new to an iterative approach are usually overly-optimistic and the first iteration is usually the hardest. In addition any infrastructure, tool or integration issues must be resolved prior to onboarding the pilot team and starting Sprint 0 activities.

Tips for Selecting a Pilot Project

Pilot selection is usually very critical. Here are 5 key points to consider: 

  1. Duration – Recommended project length at least 8 – 10 wks
  2. Size – Pick a project that can be done by a small cross functional team (between 5 – 9 resources)
  3. Importance – Select a project critical to business (more visibility)
  4. Motivated Business sponsor – an engaged sponsor can help motivates team and/or help remove organizational barriers
  5. Leadership and Experience – How motivated are the potential pilot team members to adopt agile practices 

Key Activities during Sprint 0  

During Sprint 0 planning, take on modest amount of functionality otherwise the team may not be able to complete of the committed stories or a large amount of technical debt may be incurred. Also the perception of the agile projects success may be dimmed or there will be pressure meet the commitment but not at a sustainable pace.

  • Startup Activities
    • Implement core Scrum practices (e.g. daily stand-up meetings, single product backlog, defining “Done Done” for potentially shippable code)
    • Automate processes automated build process , automated testing
  • Capture stores, requirements written in a scenarios format and work with PO to prioritize them
  • Continue grooming the high priority stories and if possible have the team estimate all high priority stories before the initial Sprint Planning meeting
  • Work with embedded testers to build relationships to help pull testing forward based on prioritized stories and user story acceptance criteria.
  • Track test case results to story cards, manage defects from iteration to iteration

Adoption Team

Finally, here are some additional considerations that the team assisting with the  adoption should take into account:

  • Special care must be taken to ensure you have consensus from the project leaders regarding the pilot objectives and the success criteria.
  • Select the appropriate metrics that help guide the team’s adoption
  • Beware of too much oversight by management. Remember the old saying “A watched pot never boils”

Succeeding with your First Agile Pilot Project

Successful agile transformations often times require successful agile pilot projects. Often time a successful initial pilot is the most critical step early in a successful enterprise agile adoption. If the pilot project is a success then the organization has a tangible example to get behind but if the project fails (or just fails to meet expectations) then the entire agile initiative could be derailed by critics. Because no one really likes change unless they are driving it.

Here is a presentation a I delivered a few years ago on running a successful agile pilot Succeeding with your First Agile Pilot Project

The presentions covers

  • Picking the Right Agile Pilot
  • Choosing the best set of Agile Practices to adopt
  • Providing the necessary education, tooling and governance
  • Learn and Adapt from the pilot

Picking an Agile Coach – Lessons from the Trenches

Picking an Agile Coach is often a trying task for most organizations. What is an Agile Coach and what qualities make a good one. These are just some of the common questions most organizations have.

As it takes time to really adopt new practices and behaviors, the Agile Coach must be more than just a recently trained ScrumMaster that usually “swoops in” to deliver words of wisdom and then makes a sharp exit. The coach must be able to spend time with the team to help them to become more aware of their workflow and how to collaborate effectively.

In a nutshell, an “Agile Coach” must help the project leaders, and the teams learn how to successfully apply the required agile practices.  The coach must be familiar with how each agile role (e.g.,  Team, Product Owners, and ScrumMaster) are impacted by an Agile Transformation as well as the roles outside the team that are impacted, especially the Project Managers and senior management (e.g., managing triple constraints or how will weekly / monthly progress be collected and shared)

Being an Agile Coach is different than a ScrumMaster leading a project team as it’s more of a transitory role not tied into project duration. However, your success / failures are directly impacted by how the team performs and grows. So while our goal as an Agile Coach is for the whole team to become self-coaching and adept in applying agile.

In many cases, organizations already have some skilled resources with some real-world experience: ScrumMaster who’s led small / medium projects and/or software developers who have worked on agile projects in the past. These organizations need coaches with experience with rolling out and applying agile practices to boost their performance and proficiency in software development as well as to accelerate their adoption of certain practices.

Common interview questions:

  • Years of experience with Agile, Scrum, XP, etc
  • Describe some of your key experiences leading agile transformations
  • Can you share some of the common challenges you ran into as an Agile Coach and how you over came these challenges?
  • How is being an agile coach different from a team lead or project manager job role?
  • Describe what you believe are some of the core practices for a team to adopt to be called agile (. Explore their understanding of Whole Team, Agile Planning to make sure they know more than just Scrum, assuming the team must scale.
  • What are some of the different roles impacted by an Agile Transformation beyond the (PO, ScrumMaster, Team) roles?
  • What techniques have you used in the past to report progress, document team performance, make adoption recommendations,  etc.?
  • Are you familiar with using tools like Rational Team Concert (RTC) to assist with agile planning, dash boarding and Adoption Activities?
  • What measures do you typically collect to determine if the agile transformation is on track?

Understanding core skills

The core skills for coaching agile teams are solid communication skills, such as listening, asking questions and giving feedback.

To engage the whole team, an Agile Coach must be able to provide one-to-one mentoring to the core roles, be effective at running meetings with good facilitation skills along with the ability to intervene when needed.

For example in his book entitled “Leading Teams”, Richard Hackman asserts that three basic types of coaching intervention: Motivational, Consultative, and Educational where he defines a coaching intervention as “any action that seeks to minimize process losses or to foster process gains.”  He further elaborates on these coaching intervention categories in that:

  • Motivational interventions improve the team’s effort by building shared commitment and minimizing free-riding
  • Educational interventions improve understanding and skills on the team
  • Consultative intervention foster process improvement by helping the team become more aware of their (mindless) habits

Further reading