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

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.

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”

What is an agile methodology anyways?

Agile methodologies is a collection of lightweight software development approaches (some would call them “best practices”) that evolved in the mid-1990s and early 2000s in reaction to heavy weight waterfall processes common in most organizations.

Common agile methodologies include Scrum, Extreme Programming, Adaptive Software Development, and Feature Driven Development.

Scrum, one of the most commonly adopted agile method, focuses on quickly delivering value to the customer by breaking up tasks into small units, called “Stories”, which developed in short time boxed iterations lasting from one to four weeks.

Teams are typically between 5-9 people with cross functional skills. Small teams help simplify collaboration and team communication. In some cases multiple small teams are formed when projects require a larger number of development resource to meet the customer goals.

Each iteration involves a team working through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders.

Using this approach, teams are able to reduce project risk by providing teams with frequent points for customer input along with focused planning sessions that helps the project to adapt to changes quickly. Stakeholders produce documentation as required.

These and other agile methods promote collaborative planning, teamwork and lightweight development and testing practices. All support one or more of the twelve principles, first articulated in the Agile Manifesto.

    • Customer satisfaction by rapid delivery of useful software
    • Sustainable development, able to maintain a constant pace
    • Close, daily co-operation between business people and developers
    • Face-to-face conversation is the best form of communication (co-location)
    • Projects are built around motivated individuals, who should be trusted
    • Continuous attention to technical excellence and good design
    • Simplicity- The art of maximizing the amount of work not done – is essential
    • Self-organizing teams
    • Regular adaptation to changing circumstances

Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.  Finally, all agile practices use “working software” as the primary measure of progress and value  face-to-face communication over detailed written documentation. And focus on working with the customer (sometimes called the “Product Owner”) to prioritize “needs” based on business value that can be achieved at the start of the iteration

References
Agile Manifesto, http://agilemanifesto.org/ Ambler, S.W. “Examining the Agile Manifesto”. Retrieved 12 December 2011.http://www.ambysoft.com/essays/agileManifesto.html
Beck, Kent; et al. (2001). “Principles behind the Agile Manifesto”. Agile Alliance. Archived from the original on 14 June 2010. Retrieved 6 June 2010.