Burn Down Charts

Why the Burn Down?

How important is status? In a high-paced environment status is very important. One way of reporting status is a burn down chart. A burn down chart is a graphical representation of work remaining versus time. On the vertical axis you will find units (hours) of work remaining. On the horizontal axis, you will find time. Figure 1 illustrates a simple burn down chart.

Figure 1: Simple Burn Down Chart

In this burn down chart, the units of work remaining are 7200. At this constant rate, this project should be completed in 31 days. The burn down chart is a much more accurate depiction of overall status than a somewhat educated guess. For example, if a sprint has 10 tasks and 8 of those tasks are completed. One may be tempted to report their status as 80% complete. This would not be the case, if the last two tasks take longer to complete than the first 8 combined. In this case, a burn down chart would be very valuable because the tasks would be measured in hours, therefore the estimated completion would be more accurate.

How do we burn it down?

Now, that we understand the importance of burn down charts. How do we get started? The first determination that must be made is how many hours will be needed to complete this sprint, iteration, or project. In many organizations, each team member is asked to estimate the number of hours it will take to complete each of their tasks for that sprint. We also need to know our deadline. With this information, we can determine what needs to be done to meet this deadline or even if the deadline can be met with the given scope and resources. This brings us to how burn down charts aid in planning.

We don’t plan the burn, the burn plans us!

As the work is completed, a comparison can be made between the estimates and the actual work, as seen in Figure 2. The burn down chart should be seen as a living graph. It can be updated throughout the project. As you can see, on the fourth day of this sprint we experienced a significant growth in scope. This information can be used to plan ahead. Should we plan to work overtime to complete this project by the scheduled deadline? Are there items that can be de-scoped from this sprint to ensure that we meet our scheduled deadline? Should the deadline be extended so that all functionality can be included?

Figure 2: Burn Down Chart with Planned and Actual Work Remaining

Instead of Burning it down, why don’t we Burn it up?

Using a burn down chart is not the only way. Many people prefer burn up charts. The burn up chart’s advantage is more information can be communicated. In Lee Richardsons blog, “Forget Burndown use Burnup Charts, he explains that in a burn up chart how much work was actually completed during a sprint can be shown as opposed to how much work remains. Also, he explains that a burn up chart can demonstrate more clearly how much total work the project contains. Figure 3 shows a burn down and a burn up chart that Lee Richardson uses to demonstrate this point of view. In the burn down chart, it appears not much progress was made in Iteration 6. In the burn up chart for the same project we see that there was a growth in scope by 20 units in iteration 6. The burn up chart more clearly explains that it isn’t true that progress wasn’t made, that in fact there was growth in scope.

Figure 3: Lee Richardson’s Burdown and Burnup Charts

Although, I will agree that the burn up chart has its advantages, I feel the burn down chart has its advantages as well. The burn down chart is a more simplified chart and is much easier to understand, and therefore more appropriate for communicating frequent status to a large audience.

Conclusion

The burn down chart is a great tool for predicting when a project will be complete. I believe Alistair Cockburn said it best. “The burn down chart illustrates the three following points: What is done?, What is left?, and How are we doing?” (2) I believe a great advantage to using either burn chart is that they allow for continuous improvements. Issues can be detected virtually as soon as they arise. If you have a growth in scope or are lacking progress for some reason, it will show on your chart and you will have the ability to plan accordingly. The last thing you would want to happen is to arrive at the last day of the project and realize the deadline will not be met.

By: Janie

References

1. “Forget Burndown use Burnup Charts”, Lee Richardson, http://www.nearinfinity.com/blogs/lee_richardson/forget_burndown_use_burnup_charts.html
2. “Earned Value and Burn Charts”, Alistair Cockburn, http://alistair.cockburn.us/Earned-value+and+burn+charts
3. “Burn Your Burn-down Charts”, Jurgen Appelo, http://agilesoftwaredevelopment.com/blog/jurgenappelo/burn-your-burndown-charts

Servant Leadership

Six Formulas to success and beyond – Servant Leadership

Leadership is the ability to influence others to enthusiastically pursue identifiable goals for the common good. There are two contrasting styles of Leadership

• Power-based: The ability to force or coerce someone to do your will, even if they would choose not to, because of your position or might.
• Service-Based: Servant Leadership involves the skill of influencing people to work enthusiastically toward goals identified as being for the common good, primarily using authority while seldom resorting to power.

We clearly know power-based approach doesn’t work too well, especially in the business world.

Why is Servant Leadership successful?

The servant-leader is servant first… Becoming a servant-leader begins with the natural feeling that one wants to serve, to serve first then conscious choice brings one to aspire to lead.
The Formula founder was Robert K Greenleaf known as Father of Modern Servant Leadership. The idea of “Servant – Leader” was developed by him in 1968. The Center for Applied Ethics, which he founded, eventually became the Robert K. Greenleaf Center is located in Indianapolis.

Formula 1:

Servant Leadership Vision:

Servant leadership begins with a clear and compelling vision of the future that excites passion in the leader and commitment in those who follow. In practical terms Servant leadership vision has three parts:

o YOUR PURPOSE/MISSION: What business you are in – How will you benefit your customers?
o YOUR PREFERRED PICTURE OF THE FUTURE: Where are you going- What will you looking like if everything is running as planned?
o YOUR VALUES: How you want people to behave when they are working on your mission and picture of the future- What do you stand for?

Formula 2:

Defining and modeling the operating values, structure and behavior norms

Formula 3:

Creating the follower environment with partners in vision

Formula 4:

Moving to the bottom of the hierarchy with service in mind

Formula 5:

Understanding the dynamics of effectively managing transformational change

Formula 6:

Applying the concepts of Situational Leadership for the growth and development of people as well as accomplishing the goals of an organization.

The following quote and proverb enlighten the Servant Leadership model.

We must be silent before we can listen. We must listen before we can learn.
We must learn before we can prepare. We must prepare before we can serve.
We must serve before we can lead.” ~ By William Arthur Ward

WHERE THERE IS NO VISION
THE PEOPLE ARE UNRESTRAINED
– PROVERBS 29:18 (NASB)

What do I get by applying six formulas?
 Seeing others achieve incredible results
 Earning recognition among peers
 Realizing personal growth experiences
 Achieving a sense of worth and making contributions
 Building confidence to face life challenges
 Impacting the world around us
 Earning salary raises
 Receiving professional promotions
 Enjoying financial incentives, including long-term compensation
 Benefiting from quality of life

Six Formulas Success Leaders in Business:

Example 1:

Alex Grass Rite-Aid Corp. founder leaves behind an enormous legacy. Grass opened Scranton discount store in 1962. That venture grew into the modern-day Rite Aid Corp. By the time he left the company in 1995 as CEO and chairman, the chain had swelled to 3,000 stores worth more than 26 billion.

Grass understood that by building human capital and consensus and helping lift the less fortunate, a community grows, and its successes, wealth and wellbeing elevate everyone with it.

Example 2:

Herb Kelleher, who created and led Southwest airlines to be among the most successful companies, He was named the best CEO in America. This servant leader emphasized that people take themselves lightly, but their jobs seriously. As an example of service to those he led, Kelleher was known to spend holidays loading baggage with ground crews.

Example 3:

Numerous proof of Formula success:
 Sam Walton of Sams and Wal-Mart
 Max Depree of Herman Miller
 Howard Behar of Starbucks
 Ken Melrose of Toro Company
 Mediatronic Company
 Marriott International
 Recent example was the success of President Barack Obama’s 2008 presidential campaign.
 Rally Software company- recently named one of the Best Places to Work in America

Example 4:

ScrumMasters are becoming successful in project management is because of Servant Leadership model.
The ScrumMaster role is very different to a project manager. The role emphasizes facilitation, leadership and collaboration over traditional command-and-control activities.

A good ScrumMaster will be a process facilitator, a servant leader to the team and a change agent within the organization.

As a process facilitator and servant leader the ScrumMaster’s role is to maximize the team’s efforts toward its goals while removing the impediments that stand in its way. As a change agent the ScrumMaster is responsible for socializing Scrum at a wider level, educating customers and other stakeholders and steering the entire organization towards essential change.

Conclusion:

The six formulas of Servant Leadership have many proofs that it is the most successful Leadership model. We need more Servant Leaders in our Business and every area; it needs to be a business-practice model. If we look at today’s economic turmoil and crisis there is lack of Servant Leadership. This leadership approach succeeds by involving and empowering employees, resulting in a more enthusiastic and engaged workforce. This, in turn, allows the organization to reach its goals and helps promote the common good.

By: Paru

References:
 SERVANT LEADERSHIP (A JOURNEY INTO THE NATURE OF LEGITIMATE POWER AND GREATNESS) – by ROBERT K. GREENLEAF
 The SERVANT LEADER (Transforming your Heart, Head, Hands and Habits) – by Ken Blanchard and Phil Hodges
 Managing Agile Projects – by Sanjiv Augustine
 http://www.greenleaf.org/
 http://www.rallydev.com/agileblog/2009/04/9-servant-and-leader-top-10-characteristics-of-an-agile-organization/
 http://www.hrtools.com/insights/paul_sarvadi/what_servant_leadership_can_do_for_american_business.aspx

Certified ScrumMaster (CSM)

Introduction

As early as 1920, Frederick Taylor introduced a change in management style in the manufacturing industry by breaking down work in manageable chunks. He also would time the best approach to get work done and then hand out management cards. [1]

Agile finds its origins back to the 1950’s when the United States Department of Defense (DoD) and NASA started using iterative and incremental development. [1]

In 1986, Hirotaka Takeuchi and Ikujiro Nonaka introduced the “rugby approach”. These included teams which would work together to gain control of a ball and move it up the field through phases. They found that bottlenecks and communication problems occur for traditional projects whenever “the ball” was handed off. Their Whitepaper, “The New New Product Development Game”, is the foundation of the Scrum approach. [1]

In the 1990’s several agile approaches started to emerge. This included Scrum at Easel Corporation, Extreme Programming (Chrysler Corporation), Crystal Methods, Rational Unified Process (IBM) and Dynamic Systems Development Method out of Europe. This eventually led to the writing of the Agile Manifesto. [1]

Why is this important?

Scrum is one of the agile project management frameworks that utilizes a collaborative approach for completing projects. The project team members are highly motivated and it is essential not to have a manager who would slow down creativity, interaction, initiative and motivation. The ScrumMaster is one of three roles within a Scrum. This person must understand that his/her role is a servant-leader and how to interact with the Product Owner and the Team. There are expectations of a ScrumMaster. For example, this person must be able to accept change. The knowledge and skills required to implement Scrum successfully are becoming apparent rapidly with the evolving acceptance of Scrum worldwide.

What is Certification?

Scrum Alliance is a certifying organization, certified by the National Commission for Certifying Agencies to define and conform to tough certifying standards regarding Scrum. [7]

The Scrum Alliance Certification Program provides the training to keep up with the increasing demand for knowledge and proficiency. Certification provides visibility to job opportunities.

A two-day Certification course provides participants with the key information to assist those to be effective and successful. Completion of this course is evidence of the commitment, competency and professionalism of those who participate

Subjects that are covered during the two-day Certification course could include: [2, 3, 4, 6]

• Scrum Master, Product Owner, and Team Member roles
• Self-Managed and Cross-functional Teams
• Agile Estimating and Planning
• Principles of Agile Thinking:
o The Agile Manifesto
o Defined vs. Empirical Methods
o The Scrum Framework and Scrum Fundamentals
• What is Scrum and Why Does it Work?
• Iterative Development, Self Managed Teams, and Visibility
• Optimizing Project and Product Value (ROI)
• Implementation Considerations
• A Scrum Launch Checklist
• Integrity in Application Development
• Scrum Team Behaviors and Variations
• Getting to “Done”
• Team Building
• Relative Priorities
• Release Planning

What steps do I need to take to become certified?

• Research the role of a Certified ScrumMaster.
• Review the Certification process and the different levels. Decide which course to take. [4]
• Enroll in a class or schedule an on-site training session. Vendors who provide training include:
o Control Chaos (http://www.controlchaos.com/about/)
o Mountain Goat Software (http://www.mountaingoatsoftware.com/
o Scrum Alliance (http://www.scrumalliance.org/)
o Winnow Management (www.winnowmanagement.com)
• Prepare for the class by downloading as much information that is available about the course. A good start is to read the Scrum Guide (from the Scrum Alliance). [4]
• Attend and participate in class.
• Take and pass an online Certified ScrumMaster Exam.
• Recertify every two years. The cost is $150.00. [4]

What is the ScrumMaster Exam?

Effective October 1, taking and passing an online exam was included in the process of being certified. The Scrum Alliance Board of Directors felt this would provide feedback on how to best improve the test and assist their trainers. [5]

There are three variations of the exams. Each exam consists of 60 questions. You will be tested on your understanding of:

• Scrum Basics. – the principles of Scrum, Scrum framework, and artifacts and roles.
• Meetings – Sprint Review, Sprint Planning Meeting, Daily Scrum, and Sprint Retrospective.
• Roles – Scrum Team, Product Owner, ScrumMaster roles and responsibilities.
• Artifacts – Product Backlog, Sprint Backlog, and Burndown charts, and how they are used.

The cost of the exam is included in the cost of your CSM course. There is no exam charge for the first and subsequent attempts to pass the exam. [5]

Once you have completed your course, you will receive an email from the Scrum Alliance with instructions for creating your profile and taking the exam. [5]

The online CSM exam is only available to those that have completed a CSM course taught by a Certified Scrum Trainer. Existing CSM’s will take the exam for re-certification starting April 2011 with no additional course required. [5]

Why do I need to recertify?

Scrum is evolving and continuing your proficiency and remaining competent in the principles, practices and skills are essential.

Do I need to remain certified to be a member of the Scrum Alliance?

Those who take either the CSM or Certified Scrum Product Owner course will be offered membership in the Scrum Alliance. However, the certification remains valid even if you don’t renew your Scrum Alliance membership. When it is time to recertify, you can decide whether or not to be a member of the Scrum Alliance. [4

Are there online certification courses available?

There are no online certification courses. Courses include interaction and participation during exercises. Scrum involves interaction and this is best taught and experienced during live courses.

Conclusion

Scrum is here. It is quickly being accepted throughout the world. Stay ahead of your traditional project management peers and become certified. Becoming knowledgeable in as many different project management methodologies will assist you throughout your career, because it will give you the flexibility to use the “best’ proven practice based on your circumstances.

By: Terry

References

1. Michele Sliger and Stacia Broderick, The Software Project Manager’s Bridge to Agility, 12-13.
2. “Certified Scrum and Agile Training – Public and Onsite Training Available”, Mountain Goat Software, http://www.mountaingoatsoftware.com/
3. “Assessment, not Certification”, Control Chaos, http://www.controlchaos.com/certification/
4. “Certification Levels”, Scrum Alliance, http://www.scrumalliance.org/scrum_certification
5. “Launch of CSM Exam”, Scrum Alliance, http://www.scrumalliance.org/news_items/74
6. “Scrum”, Winnow Management, https://www.winnowmanagement.com/scrum.html
7. “Scrum Guide”, Scrum Alliance, http://www.scrumalliance.org/resources

Scrum

I was once told that there is more than one way to skin a cat. Though skinning a cat is a gruesome thought, most likely there is a preferred way to do so. Likewise, there is more than one way to implement agile project management. In light of this, it isn’t surprising that Scrum is by far the most popular type of agile project management.

So, what is scrum? “Scrum is an iterative, incremental framework for projects and product or application development.” (Deemer, 4) According to the ScrumAlliance’s ScrumGuide, transparency, inspection and adaptation are the basis for scrum implementation. (Schwaber1, 1-2) Transparency allows the outcomes of a project to be defined throughout the project’s duration. Inspection defines any changes and/or problems and ensures that they will be handled accordingly. Adaptation is the key to being able to address the previously mentioned changes efficiently.

Now that scrum and its basic keys are defined, how is it structured? Let’s start with the scrum roles: the Product Owner, the ScrumMaster and the Team. These three roles make up the Scrum Team. The Product Owner is responsible for the ROI. To make certain the ROI is maximized, the product owner “maintains the product backlog and ensures it is visible to everyone.” (Schwaber1, 3) The ScrumMaster acts as the scrum sergeant-at-arms. He or she is responsible for making sure everyone knows and follows the rules of scrum and handles any problems (road blocks) the team may face. This is imperative to having an efficient scrum team. The Team is the group of people with technical skills needed to produce a product. Members on the team are not given tasks to do. Instead, they pick their own individual tasks to complete during a sprint.

In order to easily define who’s who in scrum, the concept of chickens and pigs was developed. Originating from the following comic strip, a chicken is “someone who is interested in the project but does not have formal Scrum responsibilities and accountabilities”. (Deemer, 20) A pig, on the other hand, is “someone exercising one of the three Scrum roles…who has made a commitment and has the authority to fulfill it”. (Deemer, 20)

Next, we’ll tackle Time-Boxes. Time-boxes are used to regulate the flow of scrum. The Release Planning Meeting, Sprint, Sprint Planning Meeting, Daily Scrum, Sprint Review and Sprint Retrospective are all time-boxes. During the Release Planning Meeting the goals of the project, a plan to reach those goals, the risks, and the product backlog are all defined. The product backlog created at this 4 hour meeting is then transferred to a sprint backlog. The Sprint is specified cyclical time period (usually 30 days) used to change the status of tasks from “to do” to “done”. If a task is not done it is returned to the product backlog. “Each Sprint is initiated with a Sprint Planning meeting, where the Product Owner and Team get together to collaborate about what will be done for the next Sprint.” (Schwaber2, 2) Sprint Planning Meetings are roughly 4 hours in duration. The Daily Scrum typically takes place for 15 minutes every morning during the sprint to monitor the progress of the team and shed light on any issues they have. After each sprint, a Sprint Review takes place for 4 hours to go over what was accomplished during the sprint and address what should be done next. Following the sprint review, a 3 hour Sprint Retrospective meeting is held to reveal useful practices and changes to be applied to the next sprint.

Finally, we’ll take a look at the Scrum Artifacts which include the Product Backlog, Release Burndown Chart, Sprint Backlog, and Sprint Burndwon Chart. These documents are used throughout the scrum process. The Product Backlog is a list of all of the requirements or features of a product. It is a living document that is adapted during the project. The Release Burndown Chart “shows the amount of work left to complete the target commitment for a Product Release”. (Wikipedia, 5) The Sprint Backlog, another living document, is a list of the tasks set to be completed during a sprint. “The tasks in the Sprint Backlog emerge as the Sprint evolves”. (Schwaber2, 3) Similar to the release burndown chart, the Sprint Burndown Chart shows how much work is remaining during a sprint.

So, there you have it. Hopefully, this brief overview of Scrum helps explain its popularity as an agile project management framework. Skinning a cat may not be on your “to do” list but project management may be. If you want to change your “to do” list into a “done” list using agile project management, I recommend Scrum. If you’re looking for something more definite and less adaptive, maybe you should try eating an elephant. I hear there’s only on way to do that.

By: Chandra

Works Cited:
Deemer, Pete, Gabrielle Benefield, Craig Larman, and Bas Vodde. “The Scrum Primer”
version 1.2, 2009: 4, 20
Schwaber, Ken. “ScrumGuide.” ScrumAlliance.com. May 2009: 1-2, 3
—. “What is Scrum?”: 2, 3
“Scrum (development).” Wikipedia 30 Nov. 2009: 5

Extreme Programming (XP)

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. The methodology takes best practices to extreme levels. Extreme Programming was created by Kent Beck in 1996 to refine the project that he is working on (in Chrysler).Although Extreme Programming itself is relatively new, many of its practices have been around for some time. For example, the “practice of test-first development, planning and writing tests before each micro-increment” was used as early as NASA’s Project Mercury, in the early 1960s. Refactoring, modularity, bottom-up and incremental design were described by Leo Brodie in his book published in 1984. (1)

As a type of agile software development, it advocates frequent “releases” in short development cycles (time boxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible.

One of the main features of Extreme programming is pair programming. Pair programming is a software development technique in which two programmers work together at one work station. One types in code, called the driver, and the other reviews each line of code as it is typed in, called observer or navigator. The two programmers switch roles frequently, possible every 30 minutes or less.

Extreme Programming is based on 5 values.

• Simplicity: Extreme Programming encourages starting with the simplest solution. Extra functionality can then be added later. The focus is on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. This is sometimes summed up as the “you’re not gonna need it” approach.
• Communication: Constantly communicate with customers and fellow teammates. The goal is to give all developers a shared view of the system which matches the view held by the users of the system.
• Feedback:
o Feedback from the system: by writing unit tests.
o Feedback from the customer: The acceptance tests by the customer and the testers.
o Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.
• Respect: Everyone gives and feels the respect they deserve as a valued team member. Developers respect the expertise of the customers and vice versa. Management respects developer’s right to accept responsibility and receive authority over their own work.
• Courage: Courageously respond to changing requirements and technology. Courage enables developers to feel comfortable with refactoring their code when necessary. Another example of courage is, knowing when to throw code away. Also, courage means persistence.

Rules of Extreme Programming: (2)
• Planning:
o User stories are written.
o Release planning creates the release schedule.
o Make frequent small releases.
o The project is divided into iterations.
o Iteration planning starts each iteration.
• Managing:
o Give the team a dedicated open work space.
o Set a sustainable pace.
o A stand up meeting starts each day.
o The project velocity is measured.
o Move people around.
o Fix XP when it breaks.
• Designing:
o Simplicity.
o Choose a system metaphor.
o Use CRC (Class, Responsibility and Collaboration) cards for design sessions.
o Create spike solutions to reduce risk.
o Refactor whenever and wherever possible.
• Coding:
o The customer is always available.
o Code must be written to agreed standards.
o Code the unit test first.
o All production code is pair programmed.
o Integrate often.
o Use collective ownership.
• Testing:
o All code must have unit tests.
o All code must pass all unit tests before it can be released.
o When a bug is found, tests are created.
o Acceptance tests are run often and the scores are published.

Extreme Programming is successful because it stresses customer satisfaction and empowers your developers to confidently respond to changing customer requirements, even late in the life cycle. Extreme Programming created quite a buzz in 1990s and early 2000. The practices in XP were largely debated with strong opinions for and against using XP. But XP is still evolving, assimilating more lessons from experience in the field.

By: Subbu

References:
1. http://en.wikipedia.org/wiki/Extreme_Programming
2. http://www.extremeprogramming.org/

Crystal

A co-author of the “Manifesto for Agile Software Development” (1) and “The Declaration of Interdependence for Modern Management,” (2) Alistair Cockburn is a self-proclaimed “project witchdoctor and IT strategist” (3) who holds a PhD in methodology from the University of Oslo (4). In the 1990s, Cockburn researched and interviewed software development teams in efforts to define IBM’s methodology. The result is a family of lightweight, agile, project management methodologies he dubbed “Crystal” (5).

All of the Crystal methodologies can be described by a number of overarching themes. Crystal professes that no single methodology exists that is suitable for all projects. To put it more positively, different projects require different methodologies. Additionally, Crystal recognizes that the primary goal of a project is a successful delivery and that process is of only secondary importance. In light of these revelations, Crystal prescribes that one should use the leanest process necessary for the project to operate effectively. This family of methodologies places emphasis on people and communication, favoring the replacement of documentation with face-to-face interactions (6). While people are the most important element in any project, they are also the most variable. Consequently, the Crystal methodologies are designed to be flexible and evolvable (7).

Crystal categorizes projects according to two primary characteristics. The first characteristic, criticality, refers to the severity of the consequences should the system fail. Criticality is described in four categories ranging from least to most critical: loss of comfort, loss of discretionary money, loss of essential money, and loss of life. The criticality of a system necessitates the level of safety measures required to ensure the system does not fail. The second characteristic, number of people involved, is measured by the size of the development team. The number of people involved in the project determines the amount of coordination needed for effective communication. When criticality is arranged along 4 segments of the y-axis and staff size along 7 segments of the x-axis, a grid (see below) is formed that can be used to select the appropriate methodology. The Crystal family is segmented into seven, color-designated methodologies by columns in the grid. These methodologies include, Clear, Yellow, Orange, Red, Magenta, Blue, etc. The criticality of the project determines the “hardness” of the particular methodology. Therefore, a 4 person project developing a life-critical system would use the Crystal Clear methodology with the highest level of safety measures (L6) (8).

Clear Yellow Orange Red Magenta Blue
Life L6 L20 L40 L100 L200 L500
Essential E6 E20 E40 E100 E200 E500
Discretionary D6 D20 D40 D100 D200 D500
Comfort C6 C20 C40 C100 C200 C500
1-6 20 40 100 200 500

In contrast to most methodologies, Crystal methodologies are described in terms of project properties rather than procedures. More colloquially, Crystal focuses on the ends rather than the means. Targeting properties is a more effective approach as any one set of procedures may not produce the desired properties in every project. Furthermore, there may be multiple, valid procedures which might achieve the properties for a single project. Crystal identifies seven properties of successful projects.

1. Frequent Delivery
2. Reflective Improvement
3. Osmotic Communication
4. Personal Safety
5. Focus
6. Easy Access to Expert Users
7. Technical Environment with Automated Tests, Configuration Management, and Frequent Integration

Of these seven properties, the first three are common across the whole Crystal family of methodologies. “Frequent delivery” refers to the practice of iterative development in which the project is organized into a series of iterations of no more than four months at the end of which running, tested, and usable code is delivered to the users. Frequent deliveries facilitate rapid and regular feedback. The property of “reflective improvement” refers to the process by which the team regularly reflects over what is and is not working and adjusts accordingly by adding and/or subtracting elements from the project methodology. This property mitigates variations in people, technologies, and requirements by evolving the methodology to suit. The third most important property is “osmotic communication” which means that information flows readily and richly with little disruption of individuals’ work. This kind of communication is commonly achieved through the co-location of team-members in the same room (9).

By providing a framework of flexible methodologies, Crystal is an antidote to the one-size-fits-all approach to software engineering methodologies. Stressing a less-is-more philosophy that emphasizes effective communication over rigid processes and documentation, this family of methodologies puts the focus of projects back on the elements that contribute more directly to success. Allowing the methodology to evolve over time ensures that Crystal methodologies will not be rendered ineffective by changes in a project’s environment. Overall, Cockburn’s Crystal presents a refreshingly human-centric suite of methodologies.

1. http://agilemanifesto.org/
2. http://alistair.cockburn.us/The+declaration+of+interdependence+for+modern+management
3. http://alistair.cockburn.us/
4. http://en.wikipedia.org/wiki/Alistair_Cockburn
5. http://www.informit.com/articles/article.aspx?p=1380616
6. http://alistair.cockburn.us/Crystal+light+methods
7. http://en.wikiversity.org/wiki/Crystal_Methods
8. http://alistair.cockburn.us/Crystal+light+methods
9. http://www.informit.com/articles/printerfriendly.aspx?p=345009

The Agile Manifesto

“The Agile Manifesto provides a philosophical foundation for effective software development.”(1) This philosophy is detailed using four core values which are further supported by a set of twelve principles. Based on real world success, The Agile Manifesto was developed “On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground and of course, to eat. What emerged was the Agile Software Development Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.”(2)

“The important thing to understand about the four value statements is that while you should value the concepts on the right hand side you should value the things on the left hand side (presented in red) even more. A good way to think about the manifesto is that it defines preferences, not alternatives, encouraging a focus on certain areas but not eliminating others.”(1) The Agile Manifesto’s four core values are as follows:
1. Individuals and interactions over processes and tools. People build software and should work in collaboration with one another to achieve peak effectiveness. Software tools and processes are kept secondary to support this collaboration (1).
2. Working software over comprehensive documentation. Teams should produce working software, not well documented failing software. Documentation is important but we should prioritize working software first (1).
3. Customer collaboration over contract negotiation. Contracts are necessary to outline roles and responsibilities but should not dissuade customer collaboration. Customer interaction will help assure purpose driven software (1).
4. Responding to change over following a plan. Rigid project plans are often important to drive milestones and outline success criteria but “the growing unpredictability of the future is one of the most challenging aspects of the new economy” (4). An inability or unwillingness to adapt to changing requirements will jeopardize a project’s success (1).
“Unfortunately there is no official criteria for determining whether or not a team is Agile, and worse yet there are many “code & fix” teams claiming to be agile.”(3) Applying these values is an important first step in true Agile Project Management.

To further support the four core values, the seventeen creators of the Agile Manifesto creators constructed twelve Principles as follows (5):
1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”(2)
2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”(2)
3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.”(2)
4. “Business people and developers work together daily throughout the project.
5. “Build projects around motivated individuals, give them the environment and support they need and trust them to get the job done.”(2)
6. “The most efficient and effective method of conveying information with and within a development team is face-to-face conversation.”(2)
7. “Working software is the primary measure of progress.”(2)
8. “Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.”(2)
9. “Continuous attention to technical excellence and good design enhances agility.”(2)
10. “Simplicity—the art of maximizing the amount of work not done—is essential.”(2)
11. “The best architectures, requirements and designs emerge from self-organizing teams.”(2)
12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”(2)

A deep understanding of these values and principles will serve our professional careers as we wade through adverse opinions and face various software development hurdles. What if your boss demands documentation to the point that software development becomes second priority? Value 2 and principles 1 and 7 teach us that customers want working software over documentation and can be used to persuade your boss to think properly about what customers really want and need. What if your boss is using the contract as a means to limit customer interaction? Explaining value 4 and principles 1, 2, 4, and 8 will help you plead your case by demonstrating how important customer interaction is to the projects success and to meeting the exact customer needs. One thing is certain, working knowledge of The Agile Manifesto will help our persuasiveness, better enable us to meet project timelines, and better satisfy customer requirements.

Every Project Manager’s goal is to deliver packages with real customer value, on time, and within budget. The Agile Manifesto helps us achieve our goals by providing a philosophical framework to base our decisions from. Let’s face it, our decisions “make or break” software development projects. Therefore, it is essential to understand and have a working knowledge of the values and principles outlined by the manifesto. Applying these values and principles to your software development projects will increase persuasion skills. You are likely to interact with many stakeholders that do not understand the Agile approach. It is your duty as a Project Manager to convince stakeholders that the best steps are being taken to achieve project goals. Failure to convince stakeholders can put your efforts in jeopardy and you may soon find that your projects are off track and doomed for failure. The Agile Manifesto plays a key role in successful software project management. It should be understood in detail and practiced throughout our professional careers to increase our likelihood of project success.

By: Brett

References:
(1) http://www.ambysoft.com/essays/agileManifesto.html
(2) www.agilemanifesto.org
(3) http://www.agilemodeling.com/essays/agileCriteria.htm
(4) http://www.ddj.com/architect/184414755
(5) Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, and Martin Fowler

Agile Project Management (APM)

A quick flash back to concepts and details of Agile Project Management will assure a better understanding of the challenges that agile techniques are designed to resolve.

THE ORIGINS
Agile Project Management’s history started in 2001 as a reaction against “heavyweight” methods. Prominent figures in the field of agile development (then called “light-weight methods”) got together looking for ways of creating software in a lighter, faster, more people centric way. This set the grounds for terms like agile methods and the Agile Manifesto was created. This document is the foundation of the agile movement.

“The concept of agile development first emerged among Japanese automobile manufacturers. These concepts quickly spread to North American car manufactures and then their IT departments in the late 1980s”(1). Once these ideas worked their way into the IT community, they quickly spread to other organizations and industries. These principles of the agile methods are generally applicable to most new product development scenarios, but more often, in the software development world, where most of the research and work on these methods has taken place.

FROM “LIGHTWEIGHT” TO “AGILE” TERMS
Agile techniques claim to place more emphasis on people, interaction, customer collaboration, and change, rather than on processes, tools, contracts and plans. The term agile was selected to denote the ability of these methods to respond to changing requirements in a controlled but flexible manner. On the other hand, lightweight methods did not highlight the applicability to projects with high levels of change.

Some of the notable “early agile methods include: Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995)”(2). These are now typically referred to as Agile Methodologies, after the Agile Manifesto was published in 2001.

WHY IS AGILE HERE? An illustration…
“The Standish Group, in their ground-breaking Chaos Reports first noted that approximately 16 percent of all IT projects are successful”(1). The rest are either late, over budget, deliver only a fraction in order to meet their time or budget restriction or are cancelled. IT projects are different from more traditional projects in a number of important ways:
• The hardware and operating systems that the project targets are constantly evolving.
• Usually trying to create unique products with a few available analogs for comparison
• Tools for building software are constantly changing, often mid-way through the project
• The software industry standards are constantly changing.

When dealing with all of this uncertainty, of course there is going to be a high level of change during a project. Now, add to this the reality of today’s business world with:
• A global economy and the faster pace of today’s business endeavors
• A competitor coming out with a new product
• Changes to governmental legislation
• Organizational restructuring with implementation of a different business strategy

Many different forces of change are at work today, and we cannot control these forces of change. What we can do is manage how we adapt to these changes.

Traditional Project Management methods are not prepared to provide ways of allowing introduction of changes into an existing project without a controlled impact in the end result. However, “successful Project Managers, no matter the technique employed, continually, and effectively communicate, build strong teams, motivate, plan, monitor, and execute projects in environments that need such an approach to timely and successful project completion”(3). Simply said, Agile Management compliments the many project management techniques from which Project Managers can choose to employ.

CONCLUSION
The Agile Manifesto was the culmination of new theories and approaches for agile development. The signatories include many of the “founding fathers of some well-known agile methodologies: Kent Beck went on to develop Extreme Programming; Alistair Cockburn became the developer of Crystal Methods and author of influential works on agile development; and Jim Highsmith has translated agile software concepts into an Agile Project Management methodology”(4).

Agile methods are based on solid research, demonstrating that these incremental, prototype-based methods solve problems and offer real benefits. Understanding concepts and practical background of agile methods better positions us to have an influential conversation with our stakeholders, and enriches our insight into the problems that agile methods are designed to resolve.

By: Alfredo

References:
(1) Kevin Aguanno. Managing Agile Projects. Introduction, Second Edition, 10-48
(2) http://en.wikipedia.org/wiki/Agile_Project_Management#History
(3) http://www.brighthub.com/office/project-management/articles/34394.aspx
(4) http://www.builderau.com.au/strategy/developmentprocess/soa/The-roots-of-agile-project-management/0,339028278,339297045,00.htm

Quality Plan

Creating a Quality Plan is essential if you want to provide the customer with confidence that you will produce a solution that meets their needs. The Quality Plan states everything you’re going to do to ensure the quality of your solution, beginning with defining Quality targets, followed by a Quality Assurance Plan, and backing both with a Quality Control Plan. By using this outline, you can create a Quality Management Plan that gives your customer a high degree of confidence that you will succeed. (2)

Quality Plan can be defined as a set of activities planned at the beginning of the project that helps achieve Quality in the Project being executed. The Purpose of the Quality Plan is to define these activities / tasks that intends to deliver products while focusing on achieving customer’s quality expectations. These activities / tasks are defined on the basis of the quality standards set by the organization delivering the product. Quality Plan identifies which Quality Standards are relevant to the project and determines how they can be satisfied. It includes the implementation of Quality Events (peer reviews, checklist execution) by using various Quality Materials (templates, standards, checklists) available within the organization. The holding of the Quality Event is termed as Quality Control. As an output of the various activities, measurements are captured which assist in continuous improvement of Quality thus adding to the inventory of Lessons Learned. (1)

Define the Quality Targets
During quality planning, we all know that it’s pretty impossible to meet your customer’s expectations until you define them. By asking your customer to state upfront exactly what it is that they require, you will greatly improve your chances of success.

Ask your customer to provide a list of their requirements for a solution to be delivered by the project. Then help them to list the key deliverables which once produced, will satisfy their requirements. For each deliverable, list its components and then go one step further by describing the detailed quality targets (i.e. quality criteria and quality standards) to be achieved by each component. This will provide you with a comprehensive understanding of exactly what it is that must be produced by the project to meet the expectations of your customer.

Create a Quality Assurance Plan
The next step is to create a plan to assure your customer that you can meet the quality targets set. By scheduling a suite of Quality Assurance Reviews to be undertaken by an independent person to the project, your customer will be provided with a “trusted view” of the overall progress of the project and the likelihood of the deliverables actually meeting the quality targets agreed. Quality Assurance processes will assure the implementation of the planned and methodical activities contained in the Quality Assurance Plan will satisfy customer requirements and provide confidence that the project will meet or exceed quality standards. Some of the activities include structured walkthroughs, in-stage assessments, thorough testing of work products, strict implementation of configuration management procedures, risk monitoring and assessment at all levels of management and development. (4)

Create a Quality Control Plan
Internally within the project, you need to create a schedule of “Quality Control” measures to control the actual level of quality of each deliverable, as it is being produced. Examples include putting in place peer reviews, deliverable reviews, documentation reviews and end-of-phase reviews. Each review will measure the deliverables produced and identify any variations from the quality targets set. All variances will be analyzed for determination of causes and unidentified risks to the project. When variances exist, action will be taken to bring the project into compliance to requirements. In addition, trend analysis will be conducted to monitor technical performance and schedule performance. These analyses will act as predictors to provide insight to potential outcomes of the project. (3)

In conclusion, a Quality Plan is a vital part of any project plan. By following the structured layout of determining the customers quality targets and defining quality control testing and standards, you can obtain the ultimate goal of reassuring the customer that their investments and goals are being met.

By: Greg

(1) http://www.visitask.com/project-quality.asp
(2) http://www.method123.com/quality-plan.php
(3) The Project Management Life Cycle: A Complete Step-By-Step Methodology for Initiating, Planning, Executing & Closing a Project Successfully by Jason Westland
(4) http://en.wikipedia.org/wiki/Quality_assurance