The Stable Framework™: Empowering Information Technology Organizations to Shift Left

In today's fast-paced and competitive digital landscape, information technology organizations are constantly seeking ways to improve software quality, accelerate time-to-market, and enhance customer satisfaction. One powerful tool that enables organizations to achieve these objectives is The Stable Framework™. This new framework supports information technology organizations in adopting a "Shift Left" approach to process quality, empowering them to integrate early, test effectively, and deliver reliable software with greater efficiency.

Understanding Shift Left:

Shift Left is a software development paradigm that emphasizes early involvement of key stakeholders, such as developers, testers, security experts, and operations teams, in the development process. It involves moving tasks that were traditionally performed later in the development lifecycle closer to the beginning. The goal is to detect and address issues as early as possible, reducing the risk of costly and time-consuming fixes later in the process. We call these time-consuming downstream fixes the "Hidden Factory."
Leveraging The Stable Framework™ for Shift Left:

1.Comprehensive Monitoring and Alerting:

Using System Thinking The Stable Framework provides organizations with a robust error detection and remediation system. By continuously monitoring assets and workflow, organizations can identify anomalies or vulnerabilities before they impact the value stream. The framework's process-based toolsets enable the appropriate teams to take immediate action, investigate the root cause, and resolve issues before they escalate.

2.Integrated Testing Environment:

To effectively shift left, organizations require an integrated testing environment that allows for early and continuous testing. The Stable Framework offers guides practitioners to identify repeatable process steps and create quality structures around each. The enables organizations to perform rigorous testing throughout the development process. This ensures that bugs and issues are caught early, reducing the likelihood of critical defects reaching the later stages of development.

3.Incident Management and Root Cause Analysis:

In a shift left approach, incident management and root cause analysis are essential for early issue resolution. The Stable Framework provides incident management features that enable organizations to track, document, and collaborate on incidents from the early stages. By centralizing incident management in a central Process Asset Library within the framework, teams can quickly identify patterns and root causes, allowing them to implement fixes and prevent similar incidents from occurring in the future. This transfers tribal knowledge into institutional knowledge.

4.Collaboration and Knowledge Sharing:

Effective collaboration and knowledge sharing are vital for successful shift left implementation. The Stable Framework facilitates collaboration through its shared Process Asset Libaray, institutional knowledge, and performance console. Teams can collaborate in real-time, share insights, and leverage collective expertise to address challenges early on. The framework also allows organizations to build a centralized knowledge base, capturing best practices, incident learnings, and troubleshooting guides, promoting knowledge sharing and continual improvement.

Conclusion:

The Stable Framework™ serves as a valuable asset for information technology organizations aiming to adopt a shift left approach. By leveraging its comprehensive process definition and improvement system, asset recovery models, incident management capabilities, automation features, and collaboration tools, organizations can effectively shift left and achieve superior software quality, reduced time-to-market, and increased customer satisfaction positioning them for success in today's rapidly evolving digital landscape.

PMI's Process Owner vs. Process Manager

PMI (the Project Management Institute) has recently introduced new content into it's curriculum....the Process Owner and Process Manager.  The distinction between these two roles seems to originate from ServiceNow's influence.

In small organizations the same person wears both hats, but in larger organizations these two roles may be split between two people.  Basically the Process Owner is a senior person responsible for "working on" the process, to improve it, while the Process Manager "works in" the process to execute it with efficiency.  A description of each role follows:

Job Description for Process Owner:

Process Owner's are responsible for the end-to-end oversight of a particular business process within an organization. Their main responsibilities include designing, implementing, monitoring, and continuously improving the process to ensure it meets the organization's goals and objectives. Process owners also ensure that the process is compliant with regulatory requirements and industry standards. They work closely with cross-functional teams to identify areas for improvement and implement changes that increase efficiency, reduce costs, and enhance quality. Other key responsibilities of a process owner include:

  • Developing and maintaining process documentation, including standard operating procedures (SOPs), process flowcharts, and process metrics.
  • Monitoring process performance using key performance indicators (KPIs) and other metrics, and identifying areas for improvement. (Note, both roles include this bullet point as it is an ongoing common point of review and discussion.)
  • Leading process improvement initiatives, including process re-engineering and process automation.
  • Collaborating with other process owners to ensure that processes are integrated and aligned across the organization.
  • Communicating process changes to stakeholders, including senior management, process users, and customers.
  • Providing training and support to process users to ensure that they understand and follow the process.

Job Description for Process Manager:

Process managers are responsible for the day-to-day management of a particular business process within an organization. They ensure that the process is executed efficiently and effectively, and that process users comply with the process requirements. Process managers work closely with process owners and cross-functional teams to identify areas for improvement and implement changes that increase efficiency, reduce costs, and enhance quality. Other key responsibilities of a process manager include:

  • Ensuring that the process is executed in compliance with regulatory requirements and industry standards.
  • Monitoring process performance using KPIs and other metrics, and identifying areas for improvement. (Note, both roles include this bullet point as it is an ongoing common point of review and discussion.)
  • Providing training and support to process users to ensure that they understand and follow the process.
  • Identifying and addressing process issues and bottlenecks that impact process performance.
  • Collaborating with other process managers and process owners to ensure that processes are integrated and aligned across the organization.
  • Communicating process changes to stakeholders, including senior management, process users, and customers.
  • Developing and maintaining process documentation, including SOPs, process flowcharts, and process metrics.

Overall, while both roles are involved in managing and improving business processes, the process owner has a more strategic and high-level focus, while the process manager has a more operational and hands-on focus. The process owner is responsible for setting the direction of the process, while the process manager is responsible for executing the process according to the owner's direction. The process owner is more involved in initiating and leading process improvement initiatives, while the process manager is more involved in implementing and monitoring process changes on a day-to-day basis.

How to Best Manage Project Risks and Issues

Managing project risks and issues is an important aspect of project management. Here are some best practices to help you manage project risks and issues effectively:

  1. Identify and assess risks: Identify potential risks that could impact the project and assess their likelihood and potential impact. This can help you prioritize and focus on the risks that are most important. List these risks in a document called a Risk Register, so that you can keep track of them.  Updated it regularly.

  2. Develop a risk management plan: Develop a plan for managing identified risks, including how they will be monitored, mitigated, and communicated to the project team and stakeholders.

  3. Proactively manage risks: Proactively manage risks by taking steps to mitigate them before they become bigger problems. This could involve developing contingency plans, adjusting project schedules, or reallocating resources.

  4. Monitor and control risks: Regularly monitor and control risks throughout the project by tracking their status and taking corrective action as needed. This can help you minimize the impact of risks on the project.

  5. Establish a process for managing issues: Establish a process for managing issues that arise during the project, including how they will be reported, evaluated, and resolved. This can help you quickly identify and address issues before they become larger problems.

  6. Document and track issues as they occur: Document all issues that arise during the project, including the impact on the project, the action taken to address the issue, and the resolution status. This can help ensure that issues are properly tracked and managed.

  7. Communicate effectively: Communicate risks and issues to the project team and stakeholders in a timely and transparent manner. This can help ensure that everyone is aware of the risks and issues and can work together to address them.

By following these best practices, you can help ensure that project risks and issues are managed effectively and that the project is delivered successfully.

How to Manage Project Scope Changes

Managing project scope and change is a critical aspect of project management. Here are some best practices to help you manage project scope and change effectively:

  1. Define the project scope: Clearly define the project scope, including what is included and what is excluded. This will help you and your team understand what needs to be delivered and what is out of scope.

  2. Develop a change management plan: Develop a plan for managing changes to the project scope. This plan should outline how changes will be requested, evaluated, and approved, as well as how they will be communicated to the team and other stakeholders.

  3. Establish a change control board: Establish a change control board or similar group of stakeholders who will review and approve or reject change requests. This helps ensure that changes are evaluated objectively and with the project's overall goals in mind.

  4. Document changes: Document all changes to the project scope, including the reason for the change, the impact on the project, and the approval status. This helps keep everyone informed and ensures that changes are properly tracked.

  5. Monitor and control the project scope: Regularly review the project's progress against the project scope and make adjustments as needed. This can help ensure that the project stays on track and within the defined scope.

  6. Manage stakeholder expectations: Manage stakeholder expectations throughout the project by communicating clearly and regularly about the project's goals, scope, and any changes that may occur. This can help minimize surprises and ensure that stakeholders remain engaged and supportive throughout the project.

  7. Identify and manage risks: Identify and manage risks that could impact the project scope or lead to changes. This can help you proactively address potential issues before they become bigger problems.

By following these best practices, you can help ensure that project scope and changes are managed effectively and that the project is delivered successfully.

Where did the term "Gherkin" originate and get used with Agile User Stories?

The term "Gherkin" is associated with Agile user stories because it is the name of a specific format for writing user stories that was introduced by the Cucumber testing framework. Cucumber is a popular open-source tool for Behavior-Driven Development (BDD), which is a software development methodology that emphasizes collaboration between developers, testers, and business stakeholders. The actual name is credited to Dan North, the creator of BDD, in a May 2006 blog post.

The Gherkin syntax is a way of writing user stories in a structured format that can be easily understood and shared by all team members, including non-technical stakeholders. The Gherkin syntax uses a simple language that is designed to be readable by both technical and non-technical people. It consists of a set of keywords, such as "Given", "When", and "Then", that describe the steps of a user story.

The Gherkin syntax is named after the small pickled cucumber, which is a reference to the idea of "pickling" or preserving the requirements of a user story in a structured, easy-to-understand format. The name was chosen to reflect the simplicity and ease of use of the syntax.

The Gherkin syntax has become popular in the Agile development community because it provides a standardized format for writing user stories that can be easily understood and shared by all team members. It can also be used to automate acceptance testing, as the steps of a user story can be mapped to test cases that verify that the software meets the requirements specified in the user story.

PMI Announces the PMI-PBA Certification!

The Project Management Institute (PMI) announced a new certification for Business Analysts.  Called the Professional in Business Analysis, the PMI-PBA is a program for business analysis, and many other professionals who perform business analysis activities.

 

Think of Business Analysis as what happens before a project, the Scope development and change management happening during a project, and the post-release RIO work that may happen after a projects.  

Before a large project concept is approved, a Business Analyst may be commissioned to perform a feasibility study, and assuming the concept is feasible, create a Business Case Analysis showing the most recommend option and a few lesser options.

Assuming the Business Case is approved by the proper authority, a project is created and the Business Analyst transfers their information to the new Project Manager and may or may not become part of the team.

If they become part of the team, they likely will manage the Scope baseline, while the Project Manager manages Schedule and Cost baselines. During this process they will also work closely with the Project Manager to implement change control.  They will also makea good 2nd witness for assessing how well the project team is working with other stakeholders.

When the project is complete, they will help evaluate the projects success criteria, which was put into the Project Charter from the Business Case they created. If the success criteria is met, the project can be Closed.  

Any post-solution deployment ROI work can be measured and calculated by the Business Analyst to determine if the target ROI was reached with the solution. This target ROI, and the pre-determined techniques to measure it are found in the Benefits Measurement Plan, also created by the Business Analyst to compliment the original Business Case. Multiple measuring points and a Statistical Process Control chart, and an efficiency frontier chart can be used to assess ROI.

Mike Berry Red Rock Research

One or Two Day Tasks

Recently while coaching Agile to a large client in the Salt Lake City area one of the developers on one of the teams asked me why an Agile team should decompose features into one or two day units of work.  It seems, he said, the particular unit of work he was considering could not be broken down into anything smaller than 4 days.

This is a common question for groups first exposed to Agile.   Decomposing features into one or two day tasks can be challenging at first.  Here are several reasons why it is a good practice:

1. Breaking down features and large tasks into one or two day units of work forces the Agile team member to really understand the nature of the tasks.  Ambiguity is the enemy of success and large units of work really are ambiguous.

2. Smaller units of work limit the amount of risk that a particular task can adversely impact a schedule that was estimated incorrectly.

3. Decomposing work into many one or two day tasks gives the team member a win every one or two days.   They and their teammates will enjoy a sense of accomplishment more frequently, helping team morale.

4. Decomposing work in to one or two day tasks creates more transparency and precision so the team can account for completed work more accurately.  This many not be noticeable for one single work item but imagine the effect if the entire team kept work items at a non-decomposed level...too much ambiguity.

5.  Some teams I encounter hold stand-up meeting less frequently than daily.  This is a mistake.  Stand-up meetings should be held daily.  When I drill down and ask why, I typically hear that the team is reporting on the same work item the whole week.  Further questioning reveals they are not decomposing work into one or two day tasks.  When they start decomposing work into one or two day tasks then they have something new to report each day, and the stand-up meetings become more helpful.

Mike J. Berry Red Rock Research

CBAP and Agile Development

I attended an excellent presentation hosted by the Northern Utah PMI Chapter, featuring Mike Sandberg, Novell's Chief Business Analysts.  Mike spoke to a room of well over 200 folks about the CBAP certification.  This is the Certified Business Analysis Professional credential that us now coming of age.Mike talked about his own experience discovering the CBAP community and about the successes and issues involved with adopting the framework.

Specifically, Mike spoke about how the PMP and CBAP roles work together.  He talked about some challenges regarding turf and terminology that sometimes befall newer groups.

Someone in the audience asked Mike about how CBAP fits in with Agile.  Mike explained that this is a common question and that the business analyst would be most suited for the Agile Product Owner role. This se to make the most sense to me, and to the others present.

Mike J. Berry www.RedRockResearch.com

Agile Development Requires Documentation

I keep hearing horror stories from managers about how their teams that have adopted Agile Development insist there are no documented requirements necessary when using the Scrum framework.This is wrong.  

Scrum is intentionally quiet about software requirements so that groups can use what works best for them.

In our training seminars, we show groups practicing Agile how they can benefit from a high-level "strategic" use case model.  This strategic model, or High Level Analysis, is used to flush out the users, the needs of the users, and to expose any data flow components. This technique has proved quick and effective.

Mike J. Berry www.RedRockResearch.com