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
Contrary to popular opinion, not every IT project can successfully adopt agile practices. Location of resources, team structure, corporate culture and even technology used, can all play a key factor in determining which development practices will work in an organization. While many companies are actively seeking to use agile practices, such as XP or Scrum to help streamline production with fast, effective development practices that can give their customers what they want in the shortest time possible, elements of some of the traditional software development methods such as the “Waterfall” or “Rational Unified Process (RUP)” are often required to bridge the gaps that some of these new practices have. In the end, most organizations must adopt a blended approach that bests fits their software project, business culture, and development environment.
In this blog, I compare the strengths and weakness of some of the traditional software development practices – Waterfall and RUP – along with providing guidelines for adopting them. In a subsequent blog will compare these process to agile practices.
The traditional software development process, is often referred to as “Waterfall”, is a highly structured and sequential process that relies heavily on up-front planning and prescribed tasks that flow from one to another like a waterfall. Typical phases in a project using Waterfall development are shown below.
Each phase usually requires its own set of subject matter experts (SME) responsible for creating the deliverables (requirements documents, design document, test plans, detailed designs, etc…) to meet carefully scripted milestones. In Waterfall, the next phase typically cannot be started until the previous one has been completed. The goal is to gather and analyze all the detailed requirements early in the process so that a complete solution can be architect-ed and build with highly predictable results.
Waterfall development can work well for complex or mission-critical systems or for and for organizations that require the highest levels of fault tolerance (such as the military or aerospace). However, projects using Waterfall processes take too long, in many cases months or years, to produce results that can be verified by the user and often and lacks the flexibility for today’s environment. In addition, because Waterfall projects require that all the requirements be defined upfront (often referred to as Big Up Front Requirements – BUFR), these projects often do not provide business value in today’s fast-paced software market as in many cases requirements changes result in expenses change requests or buggy systems.
Rational Unified Process
The Rational Unified Process® is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. RUP is “use-case driven, architecture-centric, and incremental and iterative”.
Software projects that use RUP divide the project time-line into four consecutive phases.
Inception, where the project’s scope, estimated costs, risks, business case, environment and architecture are identified.
Elaboration, where requirements are specified in detail, architecture is validated, the project environment is further defined and the project team is configured.
Construction, where the software is built and tested and supporting documentation is produced.
Transition, where the software is system tested, user tested, reworked and deployed.
Each phase is concluded with a well-defined milestonee—a point in time at which certain critical decisions must be made and therefore key goals must have been achieved. Iterations occur in each phase. Activities in iterations are focused on one of the four activities: gathering requirements, analyzing, designing, implementing, and testing. Each of these activities place a more or less important role as the project moves from phase to phase.
RUP also defines the roles and activities of team members in-depth and relies at each stage on the production of visual models, which are rich graphical representations of software systems, and specific use cases rather than the large amounts of documentation required for each stage of Waterfall. All team members have access to the same large knowledge base of guidelines, templates, tools, and other items to ensure that they share the same language and perspective on the project.
Proponents stress that it enhances team productivity by providing each team member with guidelines, templates and tool mentors for all critical development activities. While critics consider it to be too heavy, sighting the large number of documents and other artifacts that must be created to successfully adopt RUP properly. Also while RUP is an iterative approach, the Inception and Elaboration, still provide plenty of opportunity for BUFR to be produced and the remaining development cycles follow somewhat of a waterfall approach to code development and doesn’t stress the need to produce working code as fast as possible.
RUP has been around for 20+ years and has evolved into a proven software development method that has been used by many different teams in many different situations. It is easy to find resources and skills and has many advantages over traditional waterfall approach
RTC 3.0 uses three different attributes to help teams determine which work items should be done during the sprint / iteration. These attributes are: Priority, Ranking and Complexity which are covered in detail in the article Customizing the Agile Planning tools in Rational Team Concert 2.0 provides a thorough discussion of the topic with screenshots from RTC 2.x but still remains valid in the RTC 3.x release.
Can you provide some guidance on the relative ranking when assigning this to stories?
The Level of effort estimate is captured using the complexity attribute for Stories where the Story Points are often used. In some implementations Epics don’t have a complexity attribute while level of effort estimate for a Task is almost always captured in Hours, see figure below.
By default RTC complexity ranking for the Story work item uses Story Points. In Agile, a Story Point is a unit less measure of time that teams use to estimate to estimate the work that the team will commit to in a sprint. Story points are NOT meant to be directly mapped to calendar time (days/hours) for estimation but instead are mean to help teams create better estimates, often using relative estimating techniques called Poker planning.
What is the default to be used for the complexity ranking? We have 1,2,3,5,8,13, 20, and 40,100. Is it recommended to modify this?
Estimates using story points mean that if you estimate two stories; one story was estimated as a one and the other story as a value of five, then the second story is 5 times bigger than the first. If a third story is estimated as a ten then it is 10 times bigger than the value of one. Why? so that when you know your team’s velocity equals 10 and you select a 1,2,3 and 5 point story for a sprint, you know they actually add up to a sum velocity of 10.
Studies have found that most people can estimate smaller numbers better but as the number become larger people estimates become less and less accurate so the larger the estimate, the larger the error.
We should give the scrum master some guidance on this relative ranking.
While some teams use a doubling sequence (1,2,4,8…), most Agile teams start off with Story estimates based on the Fibonacci sequence (1,2,3,5,8,13…), which is the default RTC complexity attribute. This mathematical sequence is used for relative ranking. In this approach when estimating, teams are not allowed to pick a number that doesn’t exist in the sequence.
Work items are the fundamental mechanism in Rational Team Concert (RTC) used to coordinate, and track development tasks. RTC provides several out-of-the-box work items types including Epic, Story, Task and Defect. Each work item has its own workflow and associated set of attributes used to govern progress status, reporting and collaboration. Work items are the hub for linkage between many Rational Team Concert artifacts (e.g. other work items, builds, work items, and change sets), as well as providing support for integration with other products.
While RTC allows teams to link work items in any manner they choose, to keep it simple in when the customer is using the SCRUM Process Template, several of my customer implementation, I have recommended the following work item hierarchy: Epic story->Story -> Task/defect, see figure below.
User stories are a good approach to capturing customer requirements without having to create formalized requirement documents or incurring the extra effort to maintaining them. The intention is to speed up the requirement definition process, respond faster to changing requirements and communicate requirements in the language of the customer using scenarios that can be easily validated.
By default the RTC Scrum process template, Epics Stories are defined as top-level-item while Tasks are not. Each Story can be broken down into smaller tasks but it is not required. In addition we recommend that the RTC process template be updated to make the Defect a top-level-item.
Finally, RTC allows team to use the Work Item customization to create new work item types or modify existing ones in order to support the development process that your team follows. For additional information see Work item tracking on Jazz.net.
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.