Daily Scrum in 1910?

Warren mentions Henry Gantt’s desire to update project schedules daily (see post of Dec 27, 2011 http://www.projectteamblog.com/?p=190).  He met with his team daily!  I find that refreshingly visionary.  Gantt is seeing a hundred years into the future, and doing things the right way.  He’s staying on top of things in his own 19th Century way.

Sure, Gantt’s daily meetings were not the same as a Daily Scrum meeting — Scrum is not a warmed-over Gantt chart.  Gantt was simply reminding his team of the project schedule and tasks ahead, and updating his new-style chart to reflect the conditions on the ground.

That effort alone — the daily meeting — probably accounts for 75% of the success of any project.  Three cheers for Henry Gantt — 1861-1919!



Scrum Burn-down Charts

In the world of project management there are often disputes over Waterfall vs. Agile methodology.  Most people have a bent or preference and there is plenty of discussion whether Agile can fit within any typical Waterfall project.  However there isn’t much disagreement among Agile proponents on the need for a good SCRUM chart.  Check out the link below from a recent blog posted on PMI.org by Bill Krebs.  Bill has an interesting take on Tracking Burn-down Progress…


How to Create a Scrum Burn-Down Chart in Standard Time

Scrum burndown charts, or project history charts, as they are called in Standard Time help managers see the time remaining for projects in a line chart.  An example is shown below.  As many know, Standard Time is more than a timesheet.  It contains many project management features like task linking, resource allocation, earned value analysis, utilization percentages and rates.  These can be pretty boring topics unless you need to know where your project is headed.  And then they become pretty valuable tools all of a sudden.  Let’s take a look at the scrum chart.


Notice the falling line chart.  We’ll explain that shortly.


Scrum Burndown
Scrum Chart in Standard Time

The first step to creating this chart is to turn on project history.  Choose Tools, Projects and click a project to begin.  The project properties will display in the right-hand property panel.  Check the “Save task history” checkbox, as shown below.  This forces Standard Time to save time remaining for each project task when hours are entered into the timesheet.  Hours remaining are the raw ingredients for the scrum burndown chart above.


Save Task History in Standard Time
For Burn-down Chart


After turning on the “Save task history” option, now you’ll simply create project tasks and log time to them.  The image below shows a sample list of tasks.  Just remember that each task has a “Remaining” number of hours.  Those hours are plotted on a line graph in the scrum chart.  All tasks are combined to give a snapshot status of your project.  As you log daily time, those hours will fall, until they all reach zero.  Then the project is done!  You’ll see this gradual fall in the burndown chart.  Each week, you’ll notice trends developing.  Hopefully, going toward zero and completion.


Project Tasks in Standard Time



What Agile Methods Mean to Your Process, People, and Products

Studies show that most successful projects were those that followed agile principles, proving that model-driven methods are not always the best when it came to managing changes, fast-paced project implementation, or even meeting market demands.

The concept of agile development is not new. However, many technologists still stick to the age-old notion that software development can be easily designed and the outputs predicted without giving much thought to the more dynamic factors of projects, such as communication lines, people, and change.

Project managers eventually realized that a lot of projects failed because of rigid requirements, faulty design, and the inability of project teams to adapt to change. For the most part, clients or end-users’ requirements changed through the course of development lifecycles, that by the time applications were ready for deployment, the end products were a good degree different from what was initially planned. This would have been alright, except that towards the end of the development lifecycle, time and financial resources have overshot initial estimates by a good measure.

Instead of pointing their fingers at development teams or clients, project managers learned to allow adjustments in their methodologies. In fact, many studies have shown that the most successful projects were those that followed agile principles, proving that model-driven methods are not always the best when it came to managing changes, fast-paced project implementation, or even meeting market demands.

But before adopting agile practices, project sponsors and managers should ask how agile methods could impact their products, internal operations, and people.

Impact on people and their roles

A key agile principle, “individuals and interactions over processes and tools,” emphasizes communication and collaboration of project team members. Instead of defining the roles of team members, more importance is given to how well they can perform tasks as a team and create a working version of software. Teamwork cannot be overstated in agile processes, as each member can play the part of the end-user, leader, and engineer. To be truly successful, project managers should allow team members to wear cross-functional hats, communicate freely, and focus on team goals instead of individual—or role-based—functions.

While it has been initially believed that agile method worked best with co-located teams, experiences of outsourcing service providers proved that this also worked—and perhaps better—with the offshore outsourcing development models. In the first place, collaboration and free-flowing communication is the norm, and not the physical set-up of the workplace.

Impact on process

Processes take secondary priority in agile methods. Instead of going through particular stages of the development lifecycle, rapid and short iterations move the project forward, allowing for flexibility in changing the course of the project. Moreover, instead of drowning in documentation as dictated by requirements and design, most documentation is in the form of information exchange among project members. Design and actual product are often inconsistent until the deployment stage.

Impact on product and quality

Instead of delivering software that has all the knots and bolts in place according to its original design, the highest priority is satisfying the need of the customer with a simple but working version. The adage, “in perpetual beta” also applies to agile method; software improves with every iteration until all the “nice to have” features are in place. Simplicity allows for more flexibility in change requests, especially because end-users and sponsors or clients eventually discover new requirements along the way.

By ExecutiveBrief
Technology Management Resource for Business Leaders

Use Agile Method for Ongoing Maintenance?

A programmer friend of mine told me that his ongoing maintenance projects didn’t really require the Agile Method.  He said that he liked the idea, but his small team was just working on short, simple updates to an existing program.  He didn’t need a methodology to assist him on that.

We discussed the fact that the Scrum method was light, but still injected some measure of oversight into projects.  But he insisted that his ongoing work needed no such oversight.  He knew what he as doing, and didn’t need a babysitter.

Knowing this guy, I tend to believe him.  He’s been doing C++ programming for two decades, and knows exactly how to get a project done.  But the idea still bothered me.  Isn’t Scrum for everyone?

I believe the answer lies in the size and competency of the team.  Small, highly competent teams, who perform known work, can bypass the methodology.  Just like my friend said, they know what they are doing, and don’t need any “process” help.

But this guy is a rare beast.

Most engineers face a large number of unknowns, and need a simple system to guide the project team to success.  Scrum does that.  If you are unfamiliar with the method, consider getting a little help from these folks: http://www.controlchaos.com/ or these guys http://www.agilealliance.org/