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
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
Many small to medium size projects teams have successfully adopted agile practices such as Scrum but some agile teams do fail. Often as not they fail because of factors outside their control but here are some common reasons why agile project teams fail that are within their control:
Not implementing the whole process
Scaling Factors not addressed
Team not co-located or team governed like a Waterfall project)
Team too big or team has strong functional role boundaries
Team / Management not committed to Agile principles
Roles not followed (Organization compromise on the Product Owner / Scrum Master responsibilities)
When we look at the Principles behind the Agile Manifesto we find that the first principle is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable
So a failure in the context of an agile project could be stated as an “unsatisfied customer due to late or sporadic delivery of valueless software”.
But Agile provides teams with the opportunity inspects and adapt the process to make changes that help overcome these changes. In Agile a Retrospective is used to help teams improve their processes and practices. Similar to a postmortem performed atthe end of a traditional project, retrospectives allow teams to quickly identify things
They are doing well;
They should improve; and
Outside their control but are risks to the overall project
Here are some some practical tips and tricks for conducting an effective Retrospective along with some best practices for using Rational Team Concert to collect, manage and communicate the impact of the teams improvement activities.
Retrospective help teams improve and holding them at the end of each iteration has several advantages
Standing meeting focused on improving team performance (every 2 to 4 weeks) at the end of each iteration or sprint
Team prioritizes improvements and takes ownership over making changes
Team knows where they stand. Retrospectives occur right after Sprint Demo so they have the feedback from the Prod Owner
Quick-wins can easily be implemented rapidly where with traditional post-mortems happened at the end of the project with limited ability to make real changes.
Common issues that come up during team retrospectives include:
Story estimates are not acturate
Some members of the team are being pulled into other projects limiting their time
Team missed Sprint due to resource issues
Team had several tasks (e.g., DBA tasks) that only one person on the team can perform.
During the sprint that resource worked very long hours to complete his tasks and became frustrated that other team members could not do more to help with those tasks.
In another case say a team has was spending too much time dealing with failed builds. That team decided to implement continuous integration but the team does not want to risk disrupting their regular build process.
What is the default priority generally assigned? It was suggested to me that the default should be medium. We may need to provide some guidance on what constitutes a high, medium versus a low priority ranking.
Yes we recommend using Medium as the default value for prioritizing work items. Priorities are usually assigned by the Product Owner or other key stakeholder
How can you assign a task in a story to more than one person? Sometime we need to assign a task to multiple people
In RTC, each work item (Story, Defect, Task,) can only be assigned to 1 person at a time so we often recommend splitting a larger task into multiple smaller tasks, each estimated between 4 – 16 hrs of work, with a clear success criterion and linking them as children to the original task.
Agile is all about people, flexibility, trust, communication, and feedback. To be successful, an organization must instill these values at all levels in the organization. In this first of a multi-part blog, author Reedy Feggins Jr, IBM Solution Architect and Agile Coach, describes some of the common challenges that many large organizations face when attempting to adopt Agile practices on an enterprise scale, techniques that he has used successfully in the past with these organizations and the critical success factors from these Agile transformation efforts based on his four years experience helping organizations inside and outside IBM adopt agile practices.
Introducing Agile in an Organization
Within almost every business domain, companies are working to transform their software development organizations by adopting agile practices to improve product quality, team efficiency and on-time delivery. While once considered viable only for small, co-located teams, these practices are now being successfully implemented by organizations with larger distributed teams through the effective use of collaboration software development tooling such as those found in the IBM Jazz Platform to assist with in an effort to achieve these same benefits). Most successful transformations must have strong support from the top and the needs of this critical set of stakeholders must be understood. To get solid agile transformation, most organizations must focus their improvement activities on three critical aspects.
What skills do the resources have
How are the teams organized
What practical experiences do they need
What processes are currently being used? Waterfall, iterative, hybrid
Depending on the process different practices may need to be adopted or emphasized.
What tools are needed to support the practices?
Continuous Integration, Automated Testing, Agile Planning and Collaboration support
While each adoption effort is different, over the course of several agile adoption projects inside and outside IBM, a common set of principles have begun to emerge. Agile adoption efforts must be
Driven from Top down and implemented from the bottom up
Agile in its approach (Learn and Grow as situation evolves)
Adopt a test-driven adoption strategy
Driven from Top down and Bottom Up
Large-scale agile transformation requires the entire organization to be committed to its success. Most organizations can be roughly grouped into three viewed to be made of three layers of people with a varying degree of authority. Figure 1: Stakeholders in a typical organizationInterests / Needs
How productive are our delivery teams
How accurate is our planning and estimation
What are our development costs?
What is our return-on-investment? What business value are we achieving
What is our teams velocity
Is our Sprint burn-down on track
What risks have we identified / mitigated
What is our Defect Density / Test Coverage
Leadership must champion the importance of the adoption activities (such as training and mentoring). An effective program really comes from the top and unless you have their support it’s very difficult for people to adopt the programs and implement them. Recommendations include:
The team overseeing the adopting efforts must use agile techniques to Learn and Grow.
The team must establish success criteria at each level (Business level, Project level and Individual level)
As organizations scale up their agile transformation efforts, they will need to build a core staff of resources capable of assessing the needs of new teams and helping new teams to adopt the selected practices. Common challenges include:
Funding training and enablement programs. Most organizations now have budget and travel restrictions that limit most organizations ability to send people to training classes
Finding the right resources to training. Often times getting skilled resources to attend live training sessions is a big challenge in itself as most people have little time of extended formal training.
Convincing people that enablement is important—especially mid-level managers.
Scaling up training was a big challenge and while this can be overcome through virtual enablement sessions and media training, there is not substitute for face to face training
Implementation of training can be a challenge, especially across multiple locations.
While some of these concerns can be mitigated by self-paced training, virtual training and media training videos, there is often no substitute for face-to-face training. The use of advanced e-Learning techniques addresses several of these issues but there are often communication and technical difficulties that are hard to overcome. Many times scheduling and commitment are some of the largest issues that need to be constantly addressed.
Business Value Focused
First and foremost the agile adoption efforts must be focused on increasing the value of software development to the business. The practices selected and the order in which they are adopted must be selected to deliver the greatest potential value to the business. In most cases these values fall into one of the following categories:
Reduced time to market
Increased value to business
Large transformation efforts especially agile transformations are not easy. But economics are driving all organizations to seek creative approaches for cutting costs, improving performance while delivering value to their clients in this competitive marketplace. More companies are moving towards taking advantage of Lean principles to help cut waste and using Agile for Managing IT and Non-IT project efforts for maximum ROI. At IBM we often recommend an iterative and incremental approach for strategic enterprise agile transformation. This high level pattern uses adoption “waves” instead of a rigorous step-by-step procedure (waterfall) which won’t account for the evolutionary nature needed for this transformation. During each wave the team overseeing the agile transformation focuses on different agile practices that correlate to the business values driving that wave.
Wave One: (or Mobilization) Focuses on establishing a firm agile foundation and deliver initial value by establishing a Center of Excellence (CoE) staffed by resources responsible for the supporting the Agile Transformation. The CoE should be comprised of Agile Transformation team members; Mid-level managers and upper management guide the overall transformation. This team is responsible for
Obtaining executive sponsorship and commitment
Cultivating experienced agile mentors and coaches from within the organizations
Building agile infrastructure (C0E, process, tool)
Demonstrating measurable value by piloting agile practices on 1 or 2 process to show quick-wins and increase visibility
Wave Two: (or Early Adopters) Focuses on building on early success by helping a relatively small number of internal employees to become internal coach/trainers. The Agile Coaches must work with employees to develop a sufficient number of people who are capable agile facilitators (Scrum Masters). This team engages the trainers/coaches to do the following things roughly simultaneously:
Conduct awareness sessions to introduce everyone in the organization to agile concepts
Do initial cultural and process assessments to track progress over time
Start _everyone_ in the organization using the agile meta-process
These are the people will slowly take over from the external coaches. They learn about agile methods more deeply: practices, principles, variations, techniques, and tools. They learn to be effective facilitators who have the trust of their co-workers. These facilitators then become responsible for ensuring that everyone else is using the agile meta-process for effective learning and simultaneously applying appropriate agile practices.
Wave Three: (or Enterprise Transformation) Finally, the coaches work with the Agile Transformation Team to help a relatively small number of employees to become internal coach/trainers. These are the people who will take over from the external coaches. As for ongoing assistance, the coaches should be working in a consultative capacity as the organization struggles with obstacles, restructuring, and the deeper culture changes. Like any change effort, there are five critical components: sponsorship, communication, training, support and strategy. The coaches should be advising the Agile Transformation Team and management on how these five components can best be handled for the agile transformation.
Agile in it’s Approach
In the early days the project chosen to pilot Agile practices were often smaller green-field projects that were smaller in scope and relatively low risk if problems arose. But today many companies need to apply agile practices to a broader set of projects requiring the teams to adapt to many of the agile scaling factors spoken of Scott Ambler in his work on Agility@Scale: distribution, organization, and technical complexity to name a few. Agile techniques, such as test-driven development (TDD), continuous integration, iterative development, agile modeling, daily stand-up meetings, and so on are quickly being adopted within large IT organizations. Today most teams usually start with a core set of agile practices such as those found in Scrum and then extend them. For example, where Scrum uses a single prioritized list of User Stories (i.e., requirements) called a product backlog, many organizations need to take this practice one step further and use backlog to track all “value-added” work, even the non-requirement related work such as managing defects, prioritizing stakeholders needs and reviewing products of other teams, and so on. New work items, including those items identified as part of your user testing activities, are added to the stack in the appropriate place. The Product Owner, with input from the other project stakeholders has the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit. However, the Product Owner must also be responsible for making the final decision and providing information in a timely manner.
Regular Delivery of Working Software
Only valid measure of progress
Provides visible results to stakeholders
True earned value, not documentation-based “earned value”
Daily Stakeholder Interaction
Active Stakeholder Participation
A Product Owner that understands business priorities driving change to the backlog
Automatically compile, test, and style check your code
Continuous code integration is nice
Continuous system integration is nicer
Use a test-driven adoption strategy. (i.e. validates your results)
Most developers can understand and relate to identifying and fixing code smells as it relates to their development methodology or practices. But agile transformations on a large scale must also watch out for “Business smells” and “Process smells”. Business smells are issues that affect the business and are visible to customers while process smells are only visible to the development team. Some common business smells include:
Time-to-market – delivering new features to the customer takes too long
Little or No Real Value – Too many unused features by the customer.
Quality Problems – Software is not useful to the customer.
Too Expensive – Software is too expensive to build.
Pilot a proven Agile approach (e.g., Disciplined Agile Delivery) first before customizing it (don’t start by changing an approach that works)
Understand the motivation behind a specific practice before (adding / dropping)
Start with a small Pilot, prove success, learn from the pilot, and then scale Agile adoption (avoid too much change, too fast)
Impacted Teams must see value so avoid the “Checklist Agile” adoption
Avoid WAGILE (Waterfall Agile – e.g, BUFR Big Up Front Requirements)
Use a wave of change Adoption Roll out strategy
Develop new incentives that recognize team delivery instead of individual delivery
From my experiences, successful enterprise agile transformations require the proper mixture of top-down and bottom up activities. Agile transformation efforts are much smoother when buy in and continued support is obtained from sponsors high up in the organizations. Results are more tangible when the impacted teams help define the values, practices and tools to be adopted. With both approaches in play, I firmly believe that any organization can succeed.
Reedy Feggins, Jr, is a Solution Architect and Agile Coach at IBM Rational Software, a global software development company. Reedy is a certified ScrumMaster and PMP certified Project Manger. In this role, he trains, mentors and coaches teams in implementing practices such as Scrum, XP and Disciplined Agile Delivery (DAD). Reedy is also a IBM subject matter expert (SME) supporting the adoption of several IBM software development tools: Rational Team Concert (RTC), Rational Quality Manager (RQM), Rational Requirement Composer (RRC), RequisitePro, ClearQuest and ClearCase. He has extensive experience mentoring teams over the past four years has given him the ability to assess business needs, craft an adoption strategy and provide organizations with practical experience implementing the appropriate Agile adoption strategies.