Daily Scrums

A lot of time can be wasted in meetings that add little value to the overallresults of the project. Daily Scrums eliminate long elaborate meetings in favor of shorter productive ones.  The objective is to provide laser focus to indentify issues quickly and productively.

The Daily Scrum is a simple daily routine meeting, which helps the team self-organize, focus, identify and eliminate impediments to progress. The primary goal is to allow team members to get to the point by telling what they are working on and what they are having issues with. The meeting lasts a maximum of 15 minutes. All team members are required to attend personally, by phone or by proxy.

During this time, team member discuss progress, obstacles and daily plans.

Successful scrum meetings demonstrate the following features:

• Meeting should be 15 minutes or less
• Standing rather than sitting – this helps to keep the meeting short and everyone focused
• All project stakeholders should attend the daily scrum – to eliminate that need to repeat information
• Team members should only focus on: what was done yesterday, what will be done today, what issues may cause problems for progress
• The meeting should be held in the same place and at the same time every day
• Burndown charts and Status boards are updated during the meeting – which visibly records progress being made.

By adhering to the above practices, you can increase the efficiency of your team and improve the quality of your project by avoiding tedious and time-wasting meetings.

Conclusion

Over the past several weeks we have highlighted for you five ways that Agile works to eliminate waste. My hope is that you now have a better understanding about the advantages that Agile offers and its primary focus to eliminate waste and streamline the application development process.  There are many other advantages to using the Agile methodology, of which there are too many to highlight in this segment.

If you are interested in learning more about this topic, “Lean Software Development: An Agile Toolkit for Software Development Managers” by Mary and Tom Poppendieck, is an excellent book that defines how lean manufacturing processes can be applied to software development.

Kim Payne, Senior Project Manager at RSA Corp, shares how custom applications can help a business with their branding in addition to its various other benefits.

Next, in our series on how Agile eliminates waste in the custom application development process, we focus on Backlogs and how they are used to make projects more efficient and ultimately more successful; meaning more likely to be on-time, on-budget, and exceeding client expectations.

Backlogs are logs that contain lists of User Stories (see part 3 of 5).   There are two types of Backlogs, Product Backlog and Sprint Backlog. Both have a specific purpose directed toward eliminating waste and maximizing value.

Product Backlog

The Product Backlog is a list of User Stories, generated and prioritized by the Product Owner in order of value and business importance.  At this stage, the User Stories are defined at a high level and lack the details needed to turn them into functions. This is intentional; why waste time defining or documenting functions that may never be used or are not sufficient in value?

The Product Backlog is dynamic; it is constantly changing based on the measurement of business value and business priorities.

We select User Stories with the highest priority, as described on the Product Backlog, as candidates to be included in the next development iteration, also known as a “Sprint”. Next, we estimate how many of those User Stories can be completed within the iteration (see part 1 of 5).

Sprint Backlog

Which brings us to the Sprint Backlog … the selected User Stories are further defined into development tasks that will comprise the Sprint Backlog for the next Sprint or iteration.  The Sprint Backlog includes the Stories and tasks that become the planned work for the upcoming Sprint.

A Sprint is a two or three week cycle of planned development work, that will deliver one or more fully functioning features, based on the User Stories in the Sprint Backlog.

After each Sprint is completed, this cycle is repeated.  Users Stories are reprioritized on the Product Backlog by the Product Owner, refined into tasks on the Sprint Backlog, and delivered upon completion of the Sprint.

Tying it all together

The process of User Stories moving from the Product Backlog to the Sprint Backlog, ensures that only those Stories or functions with the highest value make it into the Sprint.  It eliminates any wasted effort spent on User Stories or functions that brings little or no value to the business, freeing up resources for more valuable work.

And most importantly, your company benefits from more ROI for its IT dollars.

Stay tuned for the final segment on how Agile eliminates waste in the application development process.

How are you using Backlogs to refine your businesses return on ROI?

Kim Payne, Senior Project Manager at RSA Corp, explains how using custom applications gives businesses a competitive advantage over those businesses that still use “off-the-shelf” software packages.

Here’s number 3 of the 5 top wasters that Agile addresses.  In the previous segment, we discussed iteration cycles and how that they can be used to eliminate waste in the software development process.

Standish reports that 64% of software functionality is never or rarely used.  By eliminating wasted functionality we can spend 64% more time and money on functionality that adds value and creates ROI.  Why waste money and time on functionality that will never be used?

Agile provides a way to eliminate wasted functionality by the use of User Stories and Product Backlog

Software projects often times involve requirements that are roughly defined; we rarely get the opportunity to have fully defined requirements at project start-up.  Requirements normally start out at a high level and become clearer, as you move through the project.  Why waste time developing coding and design documentation before the requirements become clear?  Often information is created so early in the process that it becomes inaccurate and obsolete, even before the functionality is delivered.  Why waste time developing documentation for requirements that will change or may never even get implemented?

Agile focuses on the just in time concept of refining and documenting requirement details, as the information is needed.  This is done through the simple use of User Stories.

User Stories

Project requirements are created as User Stories, story cards that describe the expected outcome from the deliverable from Stakeholder/Product Owners point of view.  User Stories are used to defined requirement functionality at a level that the Project Owner can describe and understand.  Project Owners are directly involved with the creation of the User Stories and in many cases become the owners of the Stories.

Each User Story describes only one function.  It should describe the role, the desired function, the reason for the function and the acceptance criteria for that function.

Example:
Role: External Customer
Function: View account information
Reason: External Customer is interested in knowing what they have ordered and payment balances
Acceptance: External Customer will be able to view account activity and transactions, both history and current.

We then estimate each story using a points system.  Each story is estimated in points, given the expected effort, complexity and clarity.  The points will be used later to measure the velocity (productivity levels) of the team.

The User Story needs to be brief taking only a few minutes to define.  It is recommended that each be written out on a 3×5 card to consciously enforce the idea of smallness.  User stories reduce waste by eliminating wasted hours spent on elaborate documentation that will never be read by the project team.

We focus on the high-priority, well formed requirements leaving the less formed requirements for future iterations where they will become more defined or eliminated.  This reduces time wasted on ill formed requirements that have no described value or acceptance criteria.

Product Backlog

These stories are then prioritized and placed on the Product Backlog by the Product Owner.  The prioritization of the User Stories becomes the iteration plan for the next release.

User Stories are refined and redefined as they more through the iteration process.  Stay tuned to find out about how to manage User Stories using the Product Backlog.

Questions

Are your teams using Scrum?
Are your teams using User Stories?
How would User Stories help define better requirements?

We have been talking about how Agile eliminates waste and adds value to the project process.  Remember the 7W’s (wasters) of lean manufacturing practices: defects, over-production, wait, transportation, movement, inappropriate processing, and excessive stored inventory.

In the previous segment, “How Agile Eliminates Waste (Part 1 of 5)”, we learned how collocated Team Environments eliminates wait time, transportation and movement.  This week, I would like to share with you how Iteration Cycles work to eliminate inappropriate processing, over-production, and inventory.

Iteration Cycles

Agile methodology is organized in such a way that it delivers project functionality in workable iterative cycles; usually in two or three week cycles.

Well-planned iterative delivery of functionality allows us to present fully functional features earlier.   Consequently, stakeholders are then able to provide earlier feedback on completed work.    The early feedback cycle allows us to identify changes early in the process, which eliminates inappropriate processing and over production of features.

Each iteration, also referred to as a production cycle, is organized to deliver one or more fully functional features. This allows stakeholders to realize the return on investment (ROI) for the functionality delivered without waiting for the entire project to be completed.  This is powerful!  This gives more value to the deliverable (inventory) and allows the team to provide JIT inventory processing.

Generating early feedback is the first step toward eliminating rework and unnecessary processing, which, in the long run, also saves time and money.

Each piece of functionality is delivered with an iteration cycle planned and scheduled, based on the reprioritization of the Product Backlog.   Stay tuned for next week’s waste eliminator, the Product Backlog.

Over the next coming weeks I will be discussing five ways that the Agile methodology can be applied to the software development process to eliminate waste. We use Agile here at RSA Corp as part of our custom application development methodology.

Waste is defined as anything that does not add value to the final product or service, not from your perspective but from the perspective of your customer.  The opposite of waste would be something that adds value to the desired result, for example more functionality, faster delivery, and higher quality.

The whole idea of eliminating waste originated from lean manufacturing practices which are based on the elimination of the 7W’s (Defects, Over-production, Wait Time, Transportation, Movement, Inappropriate Processing and Inventory).  Agile is a lean process that works to eliminate waste by removing unnecessary steps from the project process. It removes steps, reduces risk and removes the potential blockages that might normally prevent the project team from reaching its goal.

Team Environment

Collocated teams help us to eliminate three of the 7W’s (wait time, transportation, and movement). The close proximity of the team reduces communication issues and the time it takes to resolve issues.  Questions are answered quickly.  This eliminates the waiting game; reducing the time it takes for us to get a response to questions or clarifications of User Stories. Issues can be discussed and addressed quickly.

• We eliminate the transportation or movement of knowledge information, reducing the risk of miscommunication. Paired programming allows for collaborative solutions and faster switching of resources, should that be required during the project life-cycle.
• The team works as whole toward the common goal of completing the iteration.  Everyone’s input is valued and the team decides how the work will be done in order to complete each planned iteration.
• Everyone is jointly responsible for the functionality that will be included in each iteration. Each team member takes responsibility for the deliverable process and works together to formulate how to best turn the Product Backlog into the functionality needed for each iteration.
• Eliminating waste reduces frustrations and enables greater productivity and creativity. Overtime, the team will also increase its speed and at the same time reduce defects.

Interested in learning more about Agile teams? “Agile Coaching”, by Rachel Davies and Liz Sedley, is an excellent book that covers how to coach your team to become more Agile.  Trust me … implemented correctly Agile works!

Too often, projects start without clearly knowing the work required. Even high-level requirements are not enough to gauge the depth and complexities of most projects. Low-level requirements bring more clarity, but experience has shown that it is often not enough. Also, the longer the project, the more likely requirements will change to match changing business needs. So, how do you ensure projects are completed on time and within budget?

According to Project Management Body of Knowledge, scope management includes the processes to ensure projects include all the work required, and only the work required, to complete the project successfully.

Traditional project methodology forces the definition of the project scope to determine cost and schedule. With so many unknowns, this becomes a challenge and is based on experience and rough-guess estimates. As the project progresses, new requirements arise and existing requirements become clearer.

Agile methodology eliminates unknowns by starting with a fixed cost and schedule, allowing for flexibility of scope based on the client priorities. Clients (internal or external) re- evaluate requirements and priorities with every incrementally delivery.

Requirements can be changed, removed and added as long as the work remains within the mutually agreed cost and schedule. This becomes a win-win for both the client and the project team. The project team gets early feedback on deliverables, and wasted time on unwanted features is eliminated. This client involvement ensures project deliverables contain requirements that provide the most value.

Agile is able to provide customer-driven scope and value-driven deliverables, resulting in positive ROI in a constantly changing environment.

How is Agile changing your projects?

From project initiation to delivery, expectations should be monitored and managed to ensure success. What are expectations, and who owns them? Expectations are a two-way street between the client and project team, brought together through clear and constant communication. Project expectations are the client’s vision of the results of the service or action provided. This can be stated or unstated. Either way, expectations are critical to project success.

A path to better managing project expectations

· Set clearly defined expectations
· Educate expectations
· Communicate and monitor expectations
· Execute processes for early feedback

1. Set Clear Expectations
Initial expectations can be (and should be) defined as part of the project initiation process. This is the time when the expected scope, high-level requirements and success factors are defined. The overall objective of the project is outlined in such a way that it is understandable to all involved.

Initiation documents define processes used throughout the project, including change processes, communication/project reporting processes, quality management, issue/risk management, development process and work plan. It establishes and defines a basis for understanding that can be used to communicate expectations.

During this phase, strong attention should be given to ensure that objectives follow the SMART rule of goal setting (Specific, Measurable, Attainable, Realistic and Time-bound.) While these will most likely change over the course of the project, the purpose is to define common processes, understandings and expectations.

2. Educate Expectations
Educate the client and the team on the agreed upon expectations and development processes as defined in the initiation documents. This way, each will know what is expected at the start of the project.

The conversions that happen as a result of the initiation process should lead both parties to a better understanding of expectations surrounding the project deliverable, process and overall results. Listening, empathizing with client’s business needs and indentifying the drivers behind the project will provide a better understanding of their expectations. Understanding and acknowledging client expectations communicates a commitment to the overall project.

3. Communicate and Monitor Expectations
Communication is key to monitoring expectations. Reporting on project accomplishments, issues and metrics will keep clients updated and involved in the project process. This will build client confidence and help ward off any unnecessary surprises.

Monitoring not only involves reporting on project status, but also engaging in constant listening and looking for feedback. Monitoring expectations requires listening, hearing and understanding the client’s business needs even if those needs are not apparent.

Communication paths between the client and the project team should be constant, as both parties need to be knowledgeable of the other’s expectations. Even the smallest decision needs can impact or refine expectations.

Expectations don’t stand still.

Periodically step out and check to make sure expectations are still lining up with the objectives. This involves communicating with both the client and team to ensure expectations are well aligned. When expectations do change, then a shift is needed to regain an understanding of the change and make the appropriate adjustments to ensure a successful project.

4. Execute Processes for Early Feedback
Several means can bring early feedback to the project. Early feedback can aid in clarifying and realigning project expectations. Building prototypes and/or pilot review sessions into the development process will bring to light issues and conversions at a time when changes are less costly and project impact is low.

Agile project process works to present and deliver project milestones in an incremental fashion. Clients get an early view of deliverables as they are completed, which allows them to review and input future concerns as needed.

Scrum methodology involves the client in defining which requirements will be worked and when, and lets clients reevaluate future requirements at the beginning of each Scrum cycle. Involving the client in this way helps set the expectation of the deliverable and creates excitement at being involved with developing something new. Instead of users being disappointed at the end of a project when the system doesn’t do what they expected, they have ownership in the process and become reassured that the project will meet the need.

What tips do you have for managing expectations? Are you doing anything different?

The Standish group reported in 2009 that only 32% of IT projects were considered successful, leaving 24% to be cancelled before completion and 44% considered challenged. For many troubled projects, the source of the problems can be directly linked to a failure in implementing basic project management processes. Let’s get back to the basics. Here are the five basic processes for project management.

Based on the PMI standards, as defined in the Project Management Body of Knowledge (PMBOK), these five high-level processes are a framework for managing projects and are scalable to any type or size of project. Each process builds on and interacts with the previous one.

Initiating, Planning, Executing, Monitoring and Controlling, Closing

Initiating
This is the process by which the project gets started or initiated. This might be through a business case, statement of work or other document that contains the project scope, expected budget and acceptance criteria. The information contained in the initiation documents becomes the defining elements of the project planning process.

Planning
The plan is derived from the information included in the initiation documents. Planning for the project includes things like the Work Breakdown Structure (task list), Resource/Schedule Plan, Change Management Plan, Quality Plan and Communication Plan.
• The task list or WBS should describe the tasks needed to create the work
• Resource/schedule plan should plan the necessary resources and time frames to complete the tasks
• Change management plan defines the process of handling change to the WBS and subsequent initiation documents (scope, schedule and cost)
• Quality plan defines the process for ensuring quality work
• Communication plan defines how the project will be reported on and to whom.

Executing
Executing process is working the plan(s) that were created in the planning process. The plans are put into actions and the work begins. The execution of the plan may exist as one or more iterations of planned cycles.

Monitoring and Controlling
Monitoring and controlling plan(s) involves monitoring of work progress and budget spend, as well as controlling any changes involved in the Execution process of the project being executed.

Controlling of changes should follow the process that was outlined in the Change Management Plan.
Monitoring includes any status reports, matrix, or communication artifacts that were defined in the communications plan.

Quality monitoring/controlling, should follow the process that was outlined in the quality plan.
This also involves the updating and monitoring of any risks and issues that may result from the project execution process

Closing
Project closing process works to ensuring that all the work is complete, as defined by the deliverables, the initiation documentation and any resulting change requests.

This include getting customer sign-off for the deliverables, closing out the budget, defining any follow on actions and reviewing lessons learned.

While these processes may be familiar and simplistic in nature, they are often not fully implemented or practiced to a level that can be documented or repeated. This leaves the project to be managed without the basic elements that will help make it successful.

Most troubled projects can be brought back on track, by simply assessing the basics and defining the missing or lacking processes. Let’s get back to the basics.

How are these basic processes affecting your projects?