Agile processes provide visibility, flexibility, and early results through adaptive planning, evolutionary development, iterative delivery, rapid and flexible response to change.

Are you curious how others are implementing this?   Are you looking to transform your team or process?  How can you leverage Agile to bring value to your business?

The first step in making this transition is to educate yourself and your teams (development teams, managers, and stakeholders) on the benefits and processes of Agile through Agile training.  Talk to others who have successfully made the transition, and learn how to avoid potential pit falls.

Here at RSA Corp, we have implemented Agile Scrum as our core software development methodology.  Starting in January, we will be kicking off a series of webinars focusing on Agile Scrum processes, implementation and benefits.

If you are interested in making this transition or learning more about Agile Scrum, RSA Corp can help.

We welcome you to attend the Houston Agile Conference on January 20 and21^st 2012, to meet and network with our very own Kim Payne, certified Scrum Master and ALN Houston board member, and other Houston area Agile leaders and businesses who are successfully making the transition.

For more information or to register, click the below link:

http://agileleadershipnetwork.org/page/houston-leadership

First of all, if you haven’t heard of SCRUM, it’s not soap residue.  It’s an agile process for developing software.  It’s totally different than the traditional waterfall development where all the business analysis is gathered up front, the prototypes are designed and the product is built to specifications that hopefully haven’t changed since the beginning of the project.

What makes SCRUM work for businesses?  To keep it simple, it cuts out the waste, speeds up development, testing and delivery.  It also improves the quality of the product with less rework needed because the client plays an integral role and is kept very close to the project.

Alistair Cockburn, one of the initiators of the agile movement in software development, introduced this concept of learning in his book “Agile Software Development.”

The concept of “Shu Ha Ri”, is a Japanese martial arts concept that applies to the practice of learning, from beginner to the level of mastery. He wrote about three levels of practice: learn, detach, transcend and how we can apply them to our learning experiences.

Shu-Ha-Ri is a way to think about the levels of learning that we progress through as we gain knowledge about something.   The idea is that as in order for a person to master something they need to pass through three stages of growth.

• Shu: This is the beginning stage of learning where we follow and mimic the steps of others.    They focus on doing the task with knowing or worrying about the “why”.  This is a period of coping without adaption.

• Ha: The intermediate stage is the point the we begin to branch out. We gain knowledge of the “why” and start integrating what we have learned into our practice.

• Ri:  The mastery stage is a stage of continuation.   We aren’t  learning from other people anymore. We are learning from own experience and practice. We are able to adapt what we learn to their own experiences and circumstances.   This is also referred to as a state of flow, around some particular practice.

In my experience, I found this to be a true path when learning most anything.  First we start out by imitating and following, and then we move on to fluent mastery.

For example, a child learning to talk imitates the words other people in their lives are speaking not really fully knowing the meaning.   But then learning happens and the child begins to associate the word with real meaning, even though they only know how to use those words in a limited context.    Then more leaning happens (mastery) as the child begins to take the words they know and apply them to other contexts as they experience them.

However, I find myself at many different levels of learning for on a variety of differ things.    I can be a “Shu” on one practice, and “Ha” and “Ri” at others.   By the way, I feel like I have more “Ha” practices and very few “Ri” practices.

I am defiantly in the “Shu” stage on my golf game.  Just following the steps of my instructor, but still not really understanding the why’s of things like technique, club # , and such.  As compared to Roy Mcllroy’s performance at the U.S. Open, which undoubtedly classifies his practice as “Ri” (mastery).  (I don’t normally watch golf, but that was an exciting game!)

I will mostly likely never be a “Ri” at golf, so you might not want to pair up with me on the course if you’re looking to win.   But I am striving to get to “Ri” in my knowledge of other practices, such as team building, agile development, and intrinsic thinking.

So where do you find self in “Shu Ha Ri”?

You can find out more about this in Alistair’s book: Agile Software Development.

Here’s a great technique that helps in determining project feature priority.  Agile/Scrum manifesto is based on the premise of working on the high value items first.  These may be the features that bring the highest ROI, a matrix of complexity / risk vs. value, market value, etc.   Whatever the determining factor is, the prioritization of these value features is important in order to ensure that those value items are delivered first.

Story mapping is a process of defining the features/functions that you want your project to accomplish and organizing them in a way that makes the most sense (by process, menu option, user role, etc).  This provides the team, with a “big picture” view of the project as a whole.

We use this in conjunction with our “Product Backlog” (Agile/Scrum requirements list), prioritized list of user stories (requirements / features) for the team to implement.   This works well for our Sprint Planning, but doesn’t show a big picture view of the project.

This big picture view project helps in the definition, organization and prioritization of user stories (requirements / features).  It provokes communication and provides a clear path to the high value user stories.

How does it work?

Write down all the features you would like to have as a result of the project on to sticky notes (one on each).    With the help of a facilitator, classify each into groups (by process, menu option, user role, or etc.) that make the most sense.

Take different color sticky notes and write the group name for each   (one on each). Then arrange all of the features, underneath each group note, sticking them on the wall in rows/columns as the logical arrangement naturally occur.   Feature sticky notes can be moved around, as the team makes sense of the emerging flow.

Once complete, the Story Map gives a high-level view of all features and allows the team to make better decision about the high value feature sets.   The set of high value features becomes the “Minimum Marketable Feature Set”, the set of feature that most be implemented to make this project successful.   Now you know where to start!

The Story Map then becomes a boundary object, providing a mechanism where different points of view converge and enables a shared understanding to be formed. But most of all it helps in defining, reinforcing and communicating the project vision.

Happy mapping!

Kim Payne, Senior Project Manager at RSA Corp, discusses improvements on logistics and inventory tracking, especially for the Marine Industry and other similar industries.

Kim Payne, Senior Project Manager at RSA Corp, explains how customer portals adds business value.

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?

Scrum has been around for nearly 20 years but has recently gained ground as a front-runner in the agile methodology practice group. Due to its approach to project requirements and fast iterative development cycles, Scrum will gain even more popularity as businesses are adopting lean processes, streamlining controls and cutting out waste. It brings a faster, more complete development modules and project owner involvement to ensure that current and future business goals are met.

Scrum is a value-driven management agile methodology that focuses on delivering small incremental batches of requirements within some given time frame and budget. One goal is to realize business value (ROI) on deliverables as soon as possible so businesses can make more informed decisions for future Scrums.

Scrum vs. Traditional Development Methods

Scrum methodology concentrates on incremental release cycles of useable deliverables. Requirements are placed on a product backlog list, which are then detailed into the Scrum backlog and pulled into a release for work. Project owners have full control over the backlog list and the priority of the work that is schedule to be done in each release. The release dates and budget for each Scrum iteration or sprint remain fixed, while the requirement (scope) remains flexible.

“Flexible scope” is a scary phrase for any project manager. In reality, when a project begins with high-level requirements and scope, the result is often different from the start. Throughout the project, the requirements are revised, changed and sometimes even removed.

With the Scrum methodology, both the cost and time for each iteration are fixed, ensuring budget and schedule control, while the project owner controls requirements (scope).

The process starts out with a backlog of requirements that the project owner prioritizes. Then, the project team decides how many requirements can be placed in a Scrum sprint. Requirements are further detailed and placed on the Scrum backlog. This is a just-in-time process for feeding into the Scrum sprint. It’s recommended that sprints run 1-3 weeks, depending on the needs of the project. The point is to keep them small, delivering working product frequently.

This allows for ROI to be recognized sooner than with traditional methods. Waterfall methods do not make ROI apparent until closer to the project end, which in some cases can be years. This makes Scrum a fiscally advantageous methodology for long-term projects.

Waterfall methods often result in systems that no longer provide the expected value because they’re out of date by the time of delivery or are in a never-ending mode of change. Scrum value-driven management helps to avoid these issues by quickly delivering high-priority requirements (as denoted by the product owner), which allows the product owner to revaluate the benefits of each requirement and adjust as needed.

Would faster delivery and ROI be factors in making a decision on a project methodology?