Monday, July 3, 2006

NOTes

I recommend that you take down notes on all the different features you’d like to create. This can be written on paper or stored digitally with any to-do list application. These notes should be rough concepts and it’s your job to go over them and pick out which ideas are worthwhile. Take your top 5 and start building to see what you can achieve.
Try to keep your ideas small and easily manageable. During the first few weeks after launching it’s best to focus on smaller goals which you can complete in 1-3 days. If your idea is going to require 2 weeks for implementation it may be wise to break things down even further. Attempt to complete smaller chunks so you don’t end up feeling burnt out from working consistently.

Monday, April 25, 2005

Sprint Planning Meeting

Today I want to tell you a little bit about our Sprint planning meeting.  Today we started our next two week Sprint for the current project we are working on.  In scrum you start each spring off with a Sprint planning meeting.  What this does is allows the team to decide on how many user stories they will be able to complete during the next sprint. The Product Owner is responsible for prioritizing the most important user stories or functions that the customer will get the most benefit from. The team starts at the top of the list and estimates how many story points each story is worth.  In our case, some of this was done during the last sprint, we took about two hours a week to groom the backlog.  With this we were able to have some of the planning done before we started our Sprint planning meeting.  We decided how many user stories we could complete this upcoming spring, in this case we settled on 30 story points.  On our first sprint we thought we could complete 55 story points and actually only completed 23.  From there we backed down to 25 story points and were able to complete 27 story points.  We have progressively increased our velocity since then and are now working at about 30.

During the second part of our spring planning meeting the team breaks down the user stories into task.  There is not a whole lot that I have to do during this time since I am the scrum Master.  I usually go about my business taking care of issues that will slow down the team.  Once the team has broken the user stories down into task they began to start development by taking a task to work on.

Monday, April 4, 2005

Job Update

Lots of new things to learn.  It seems a little crazy right now.  I have been reading and studying about this for several years now.  It is a lot different once you actually get into it.  I like it, I just feel like there is so much more to learn and do before I can feel confident.

Our first sprint was way under what we planned. 41% below to be exact.  Hopefully things will speed up here next round.

Friday, March 18, 2005

New Job

I just started my new job with a website that creates videos and classes on Scrapbooking.  Yes you heard it right, scrapbooking.  Guess I will be learning alot about that in the future.  The cool part is that I am finally getting to work in a real agile environment using Scrum.  Right now we are just getting everything together and all trying to get up to speed on what it is we need to make.  We are using "user stories" as a part of the requirements.  We should get started rather quickly.  The idea is to get working software as fast as possible.  Every two weeks we will add new functions that will be usable.  Once the customer feels there is enough usability to go live we will and then keep adding on after that.  Looking forward to it.

Tuesday, March 15, 2005

Agile Methodologies for Software Development


 Good article on different methodologies.


The various agile methodologies share much of the same philosophy, as well as many of the same characteristics and practices. But from an implementation standpoint, each has its own recipe of practices, terminology, and tactics. Here we have summarized a few of the main methodology contenders:

Scrum

Scrum is a lightweight agile project management framework with broad applicability for managing and controlling iterative and incremental projects of all types. Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed significantly to the evolution of Scrum over the last decade. Scrum has garnered increasing popularity in the software community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.
In Scrum, the "Product Owner" works closely with the team to identify and prioritize system functionality in form of a "Product Backlog". The Product Backlog consists of features, bug fixes, non-functional requirements, etc. - whatever needs to be done in order to successfully deliver a working software system. With priorities driven by the Product Owner, cross-functional teams estimate and sign-up to deliver "potentially shippable increments" of software during successive Sprints, typically lasting 30 days. Once a Sprint's Product Backlog is committed, no additional functionality can be added to the Sprint except by the team. Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized, if necessary, and the next set of functionality is selected for the next Sprint.
Scrum has been proven to scale to multiple teams across very large organizations with 800+ people. See how VersionOne supports Scrum Sprint Planning by making it easier to manage your Product Backlog.

Lean and Kanban Software Development

Lean Software Development is an iterative agile methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement, and the practices of companies like Toyota. Lean Software Development focuses the team on delivering Value to the customer, and on the efficiency of the "Value Stream," the mechanisms that deliver that Value. The main principles of Lean include:
  1. Eliminating Waste
  2. Amplifying Learning
  3. Deciding as Late as Possible
  4. Delivering as Fast as Possible
  5. Empowering the Team
  6. Building Integrity In
  7. Seeing the Whole
Lean eliminates waste through such practices as selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers. Lean uses the idea of work product being "pulled" via customer request. It focuses decision-making authority and ability on individuals and small teams, since research shows this to be faster and more efficient than hierarchical flow of control. Lean also concentrates on the efficiency of the use of team resources, trying to ensure that everyone is productive as much of the time as possible. It concentrates on concurrent work and the fewest possible intra-team workflow dependencies. Lean also strongly recommends that automated unit tests be written at the same time the code is written.
Kanban is an agile methodology for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.
Kanban is based on 3 basic principles:
  • Visualize what you do today (workflow): seeing all the items in context of each other can be very informative
  • Limit the amount of work in progress (WIP): this helps balance the flow-based approach so teams don’t start and commit to too much work at once
  • Enhance flow: when something is finished, the next highest thing from the backlog is pulled into play
Kanban promotes continuous collaboration and encourages active, ongoing learning and improving by defining the best possible team workflow. See how VersionOne supports Kanban software development.

Extreme Programming (XP)

XP, originally described by Kent Beck, has emerged as one of the most popular and controversial agile methodologies. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices:
  1. Planning Game
  2. Small Releases
  3. Customer Acceptance Tests
  4. Simple Design
  5. Pair Programming
  6. Test-Driven Development
  7. Refactoring
  8. Continuous Integration
  9. Collective Code Ownership
  10. Coding Standards
  11. Metaphor
  12. Sustainable Pace
Don Wells has depicted the XP process in a popular diagram.
In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as "User Stories". The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration by iteration basis. In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.

Crystal

The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others, whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.
Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions. Alistair Cockburn, the originator of Crystal, has released a book, “Crystal Clear: A Human-Powered Methodology for Small Teams”.

Dynamic Systems Development Method (DSDM)

DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994 with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling Agile and iterative software development projects.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.
Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:
M – Must have requirements
S – Should have if at all possible
C – Could have but not critical
W - Won’t have this time, but potentially later
All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.
The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as Extreme Programming and the Rational Unified Process.

Feature-Driven Development (FDD)

The FDD variant of agile methodology was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occured as a result of collaboration between De Luca and OOD thought leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results. FDD designs the rest of the development process around feature delivery using the following eight practices:
  1. Domain Object Modeling
  2. Developing by Feature
  3. Component/Class Ownership
  4. Feature Teams
  5. Inspections
  6. Configuration Management
  7. Regular Builds
  8. Visibility of progress and results
FDD recommends specific programmer practices such as "Regular Builds" and "Component/Class Ownership". FDD's proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other agile methods, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.
The notion of "Domain Object Modeling" is increasingly interesting outside the FDD community, following the success of Eric Evans' book Domain-Driven Design.

Original Article

Tuesday, March 1, 2005

77.6

New study finds we live longer.
Declines in death rates from most major causes — including heart disease and cancer — have pushed Americans' life expectancy to a record 77.6 years. Women are still living longer than men, but the gap is narrowing.

Monday, February 21, 2005

Feb 21 Update

Things are getting busy around here.  We have three more albums to release and I still have a plate full of work to finish before March.   I'm looking into getting my PMP but not sure if I should spend the time on it now or not.  I am moving into a new job which will not require it at this time.  I will be working with an ecommerce company developing software in an agile scrum environment.  The PMP might not be worth it at this time.  I'll let you know.