Tag Archives: Agile

Recipe for Optimization: Waterfall, Agile, and Scrum

Many firms try to graduate from Waterfall to Agile without completing the journey. The team may be embedded in an organization with strong ties by leadership to the traditional project plans with milestones. How can three schools of thought coalesce into an SDLC where all sides (mostly) buy into the resulting process?

The challenge with integrating new tools and process updates is to make sure there are no gaps in the new, incremental process. The more changes in people, processes, and technology, the greater the need to independently assess the target state SDLC.

Capability Maturity Model (CMM)

The Capability Maturity Model (CMM) is a development model created in 1986 after a study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. The term “maturity” relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes.

The model’s aim is to improve existing software development processes, but it can also be applied to other processes.

Capability Maturity Model (CMM) Wikipedia

Tools Help Shape and Reinforce Product Life Cycle

Process Requirements: Epics, Features, and User Stories

From a top-down perspective, a discrete hierarchy of requirement elements helps logically organize the product requirements and so much more. An Epic is the highest level of requirements definition, which is a Theme of Features bundled together, e.g., for a major release. Features are the “next level” requirements definition and are associated with Epics as children. User Stories are the detailed level requirements and are usually formulated in the form of a narrative. Similar to use cases, there are personas or actors that operate on the product/system and design the implementation of a Feature. Successfully defined user stories have “Acceptance Criteria” for which the QA and/or Product Owner declares the User Story has been implemented according to spec.

Tools for Manging Requirements Implementation

Many SDLC requirements management products, such as Microsoft Azure DevOps and Atlassian JIRA, allow you to define a product backlog of Features and User Stories to be implemented by an implementation team. In addition, the QA implementation team members can create test coverage, i.e., associating Test Cases to each of the User Stories to be executed once (or in parallel to) the user story state has entered some form of “Test Ready” state. Finally, the implementation team may create Tasks as children to a User Story to help granularly track the implementation, such as Database Tasks, UI Tasks, or Interface Tasks.

Agile Manifesto on Documenting Requirements

The Agile Manifesto reinforces the “right” amount of documentation:

Working software over comprehensive documentation

That is, while there is value in the item on the right, we value the items on the left more.

The Agile Manifesto

Classically, in Waterfall SDLC, we await completed documentation such as the finalized Business Requirements document and technical specifications. Leveraging an Agile approach, a Sprint can incorporate incremental business requirements definition and iterate with evolving documentation. In addition, User Stories dictate the requirement in a practical way, where we can see the Persona travel through the User Story, ultimately meeting the “Acceptance Criteria”

There’s Nothing like a Good Gantt Chart

Visual timelines for tasks and milestones, showing dependencies between tasks and predecessor definitions dynamically push dependent work items. Typically, classic waterfall maps out milestones “going beyond the near-term.” Agile may look toward the delivery of one or two sprints ahead, sprints varying in time between one to six weeks each. In some instances applying SAFe, Scaled Agile Framework may instantiate a Product Increment [Sprint], which attempts to plan 8 + weeks ahead.

There are several ways to overlay classic Gantt chart visuals over the product backlog delivery timeframes. Depending on the toolset you use, such as Microsoft Azure DevOps and Atlassian JIRA, these visuals may be provided “out of the box” or leveraging 3rd party extensions, or even exporting the product backlog data to be reported using a 3rd party tool such as Microsoft Power BI.

Burndown Delivers Value

Neophytes to Agile will not be initially exposed to Burndown Charts. Scrum masters, akin to project managers, attempt to measure the health of initiatives using Key Performance Indicators (KPIs) and, in the case of Agile and Scrum, leverage sprints, story points, and average sprint velocity.

Burndown Release Chart
Burndown Release Chart
  • Story Points Remaining” – All of the user stories contain “Story Points.” Story points are derived from collective, relative effort estimations. Each person on the team guesses the size of each story based on other stories previously estimated. Implementation team members use a consistent scale for estimations, such as the Fibonacci Sequence. All implementation team members estimate each story and speak their answers at the same time. Then a consensus is achieved for a given story. Story Points Remaining is an aggregate of points for a defined major/minor release.
  • Items Not Estimated” – are stories in the “initiative” product backlog that have not yet been estimated. This number can skew the overall burndown estimated completion date/sprint by inflating the number of points still remaining. but are currently unknown. i.e., “Projected Completion” will not be accurate.
  • Total Scope” – is the total number of story points for the “initiative” regardless of user story completion status. There may be an upward tick of Total Scope, as we are agile and are able to accommodate for changes or increases in scope. over the course of the initiative.
  • Remaining” is the bar chart that shows a downward trend in the remaining scope for the initiative. The remaining may also have an uptick in user stories as we see “Items Not Estimated” become estimated.
  • Burndown” should be a downward trend, and based on the tool that derives this graph, it may predict the projected completion of the initiative based on several factors, including average total velocity per sprint.

Daily Scrum v. Daily Status – Removing Blockers

Daily, Weekly, and Biweekly status update sessions with the implementation team are no match for Daily Scrum sessions, which primarily focus on Blockers. Blockers may be Issues that impede progress for the implementation of User Stories. We all focus on unblocking team members so they can implement stories and we can earn Story Points.

Collective, Relative, Effort Estimations

The classic developer SWAG for effort estimations is “two weeks.” None of which may have any basis upon reality. Performing relative effort estimations allows the team to apply a reproducible methodology. We compare the size of a change relative to other changes we have made to the system. Any scale will do so long as you consistently apply the method. For example, you can use tee shirt sizes, Extra Small (XS), Small (S), Medium (M), Large (L), or Extra Large (XL).

Some teams use a sequence of numbers. One most notably used is the Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21, 34, and so on forever. with many of my teams, we use 1,3,5,8,13, and 20, a “modified” Fibonacci Sequence for 3-week sprints. If using user stories as the team’s discrete unit of requirements to implement., each story can have “Story Points,” and these points are populated using the Fibonacci Sequence. Your team can equate

  • 1- one day or less; ideal for a small change or spike
  • 3 – three days or less for change to implement
  • 5 – one business week
  • 8 – Week and 1/2
  • 13 – 2 weeks
  • 20 – 3 weeks

When deriving “Story Points,” the implementation team must agree that story points are inclusive of system integration testing.

Perception – Stakeholder Point of View

Stakeholders want to have a holistic review of the project/product health. Actually, that is just some stakeholders. Other stakeholders may just want to know how many open Bugs currently exist with the severity of one. The Scrum Master can develop dynamic reports and dashboards for whoever wants a peek into the product/project health in Azure DevOps and other tools.

Charts help communicate a message and help shape our point of view. Different project stakeholders have different needs of perspectives. Both Agile principles and Waterfall methodologies inspired visual mediums that reflect the Key Performance Indicators (KPIs) of a project or product evolution.

Agile, what have you done for me lately?

At the end of each sprint, during the Scrum, Sprint Close ceremony, the implementation team members demonstrate/discuss each of their completed user stories. The Product Owner (PO) accepts or reopens the user story based upon the Acceptance Criteria being met. Each user story that is accepted by the Product Owner has Story Points associated with it. All the accepted user stories “earn” story points for the team, and the points are accumulated for each sprint which is the velocity of the team for each sprint.

There are lots of ways the Sprint Close can go “Pear Shaped”.

  • “Acceptance Criteria” was not as detailed as required; the user story results were not entirely what was as expected by the Product Owner.
  • The implementation team took on too many stories and were not able to start/complete the projected stories for the sprint.
  • By failing to deliver on the Sprint “Open/Planning” committed Story Points, the average velocity of the team’s sprint may likely go down.

As a team, make sure you are prepared for the Sprint Close by performing Product Backlog Refinement days before to confirm things like “Acceptance Criteria” verbiage with the implementation team and the Product Owner. Work in Progress or WIP limits could help the team focus on their bandwidth and apply constraints to how many user stories the team can work on at one time, thus minimizing over-promising the Product Owner.

Waterfall Gates Persist

  • User Acceptance Testing – The business team(s) insisted they validate anything before it goes into the production environment.
  • Approvals from Internal Teams – conformity to organization architecture standards, for example, must be approved when changes in target state architecture changes are proposed.

Questions and Comments Appreciated

Please let me know if I missed any other Agile, Scrum, and Waterfall areas that can cohabitate/coalesce into cohesive SDLC.

Azure DevOps: In Search of Exceptional Reporting Falls Short of Expectations

Azure DevOps (ADO) reporting “out of the box” or leveraging extensions lacks robust project delivery timeline reporting many are reliant upon for conveying project timelines. Integrations by Microsoft DevLabs such as “Delivery Plans”, “Feature Timelines,” and “Epic Roadmap” all fall short of making the mark. Why? The ADO product targets Sprint delivery and primarily focuses on reporting with the most common graphical paradigms for measuring Project / Sprint progress, such as the Sprint Burndown rather than a Gantt chart.

Still Can’t Print

Sounds like a small ask, but it’s not. None of the aforementioned Azure DevOps Extensions gives the user the ability to print out timelines. I don’t think anyone said, “let’s not let users do that”. Printing out “Gantt-like” charts is not easy with special formatting constraints. If you’ve ever tried to print out an MS Project Gantt chart, you would know the pain of adjusting print parameters to get it just right, e.g., fit to NN page(s)

Still Can’t Share Outside Azure DevOps

This kind of relates to the “Still Can’t Print” issue. In the best-case scenario, users should be able to print their “Gantt like” charts to a PDF, and then the PDF can be used to externalize and vocalize the timelines, for example, with the “Feature TImelines” extension. Yes, you can send a link to these timelines visualizations; however, the user who will try and click the link will need to have some license setup in ADO to see the page.

Reporting Across Projects and Teams within an Org

The Azure DevOps “Delivery Plans” extension has finally empowered users to report across any and all projects across your ADO organization. In addition, filtering by a Team is also available if you have multiple teams working within a project. A portfolio manager could look across their portfolio of projects and only see what is relevant to them.

Markers

The Azure DevOps “Delivery Plans” extension allows the user to add markers/milestones to a project timeline. Product “release indicators” could be added to the timeline.

Delivery Plans Extension

Delivery Plans seem to be the most promising visualization tool, with additional capabilities noted:

  • Styling Rules (Colors, Bold, Italic, Underline)
  • Fields Displayed on Cards (up to 17)
  • Tag Colors

Drawbacks to Implementation

  • Field Criteria doesn’t include AND | OR Logic
  • “Feature Timelines” does a vertical “Group By” Epic, which seems to be a better “delivery focused” view showing which features will be delivered within a specific Epic instead of delivery grouped by Team. At least we should have the option to do either.

Power BI with Gantt Chart Reporting Against ADO

The closest you will come to Azure DevOps Project Plan reporting will be to utilize the Azure DevOps data source from within Power BI and install the Gantt Chart Visualization designed to report on ADO.

Tools of the Trade

2nd Edition – July 2021

Project Managers, Scrum Masters and Agents of Change

If you’re working on any type of project as a Project Manager, Scrum Master, or are part of any change management process, these tools should be in your technology toolkit. Over the years I’ve adopted the tools listed here. Some of these products were already part of the corporate environment, so I was required to use them, sometimes to my chagrin. In other corporate environments, I had the freedom to identify, select, and adopt one or more of these tools for teams I led. I hope this article introduces you to the next tool in your toolkit.

Project and Product Management Tools

Regardless of project implementation methodologies, as an agent of change, tracking requests for change, and approved changes for implementation should be quantified for effort and costs associated with the changes. Categorizing, classifying, prioritizing changes are all possible if changes are captured, tracked and opportunities compared.

Project and Product Management Tools
Project and Product Management Tools

Automation / Workflow

Project management automation? You bet!

Automation/Workflow
Automation/Workflow

Collaboration

Anyone not interested in a collaborative environment for dynamic projects doesn’t know the statement “Share the Blame, Pass the Credit.”

Collaboration
Collaboration

Communication

“There are no words to express…” so say it in a beautiful, graphical presentation that will get your message across.

Communication
Communication

Documentation

Meeting Minutes, Standard Operating Procedures (SOP), Functional Specifications, random notes, images of error messages, etc.

Documentation
Documentation

Financials / Project Reporting

I once had to track a project “THIS BIG“, and it came with a few accountants in tow.

Financials / Project Reporting
Financials / Project Reporting

Download a PDF of the Project Manager / Scrum Master Toolkit

Products in Use Today, and Additional Tools

This list is to highlight the most recent tools I’ve used “in the field”.  Just because I’ve omitted a product or service, it doesn’t mean I don’t advocate their use.  Please see the archive file below on additional tools I’ve used prior to my most recent engagements.

Last Published PM/SM Toolkit from 2017 ( Archive for Reference)

Want to Have Your Product Evaluated?

If you’re interested in a product review of your software targeting Project Managers or Scrum Masters, please contact me with your product information, and I will follow up.

Great Tips for DevOps Teams Running on Kanban

Highlight WIP Bottlenecks

If the team is constantly dealing with production issues, the Kanban board should reflect both new functionality, User Stories and Production issues side by side. Add a “Production Priority” Swim Lane on top of your Kanban board. Visualizing high-priority production issues may have the team reconsider the priority of issues in contrast to new user stories.

Derive Effort Estimations for Input to WIP Prioritization

Team members should use effort estimations to help them prioritize their “Committed” work items. One of the work items, e.g. User Stories, may “cost” disproportionate to the value add, ROI. Focus team member efforts to provide maximum value proportionate to the time spent on work items.

Customizing States for Broad Granularity

New, In Progress, and Closed may not suffice to express work item states. “New” may represent the backlog of items, a queue not yet committed to by a member of the implementation team. Once a team member commits to implementing a user story, “In Progress” may be too wide a meaning, so adding the following states may keep the team in sync with their business process:

  • Committed – team member commits to implementing work item, E.g. User Story, or Task
  • Triage – deeper dive into the committed body of work to confirm crisp “Acceptance Criteria” and perform relative, effort estimations
  • Dev Complete – could indicate code complete, and dev testing conplete
  • Accepted – a “Closed” status indicating the Product Owner has verified the functionality is implemented in line with expectations, I.e. met Acceptance Criteria

Multicolored Cards Enable Teams to Classify at a Glance

Using different colors for Kanban Board cards allows the implementation team to prioritize work; e.g. Infra Task; E.g. User Interface or API stories. On many implementation teams, members might have areas of expertise such as UI or DB. Those members may hone in on items that are more relevant to them.

Tag, Your IT

Applying tags to Kanban board cards is another level of collectively classifying work items on the board, similar to the multicolored card approach but more diverse, not enough stark color contrast to classify.

Delineation of Work Items, Segregated by Tech Stack

Building any multitiered solution is not just creating a User Interface to render the data, there is most likely a service tier that fetches data from a database, and serves that data up to the UI to then be rendered. How do you derive work items in your product backlog? One User Story, and multiple child tasks, one task per tech stack tier, UI, service tier, and database? Or three user stories, one per tech stack tier?

User Stories Defined, Per Tech Stack Tier

There are clear advantages of representing most work items with User Stories such as deriving story points, determining team average velocity, and a more accurate burndown chart depicting a downward trending scope and implementation of user stories.

Using child Tasks of user stories may obfuscate the total work required to implementation of the solution unless baked into the parent story points. Tasks are typically tracked in terms of hours, and separately user story points are calculated/derived from a collective, relative effort estimation, e.g. Fibonacci sequence; 1,3,5,8,13,20…, and many teams may overlay this scale to fit their sprint duration.

Feature and Story Planning – At a Glance

In order to organize each feature, and correlated user stories, teams may use a prefix in the title of the user stories, such as [UI] or [DB]. At a glance, a product owner, or the implementation team can see if all the required stories for a given feature have all the elements required to implement the feature. For example, if a new report needs to be created, multiple stories must contain [UI], [API], and [DB] stories.

Drawbacks – Accepting a User Story as Complete

If you segment your product backlog user stories based on tech stack, you may need to wait until all related stories, UI, API, and DB have been implemented. For example, If your API and DB stories are developed, and not the User Interface (UI), you’re QA/Testing may not start until the UI story has been deployed. Of course, your tester could test the API using testing tools like SoapUI.

Agile Advisor Plugin for Microsoft Teams

Estimated reading time: 3 minutes

Advisory Role in Microsoft Team Communications

Agile Advisor Plugin for #Microsoft Teams is able to observe team interactions, such as conference calls within Microsoft Teams. The Advisor can derive “dialog intents” and provide recommendations for improvement. A retrospective on communications, such as Scrum ceremonies

Voice Recognition During Teams Meetings

Technology that leverages voice recognition, such as Interactive voice response (IVR) solutions are fraught with failed recognition. IVRs are used to answer calls in just about every company, which prompts for either a phrase from the user on what they want and the ability to enter a numeric value correlating to the desired intent. Challenge #1.

Dialog and Intent Identification

Beyond trying to identify the user’s intent from a phrase or sentence, a dialog, a series of interactions between two or more team members is even more complex. Current AI models that identify intent from a sentence or phrase have a mixed variable of accuracy, which is why these models must be tuned over time. A collective of interactions, a dialog between two or more team members, has a much higher level of complexity to identify intents. Challenge #2. Once a dialog intent(s) has an “N”% level of accuracy, rules may be fired with any number of outcomes, such as unintrusive logging of Agile suggestions for best practices, and next steps: e.g. a retrospective of the scrum ceremony.

Dynamically Identify Roles in Teams Meetings

Who participates in Microsoft Teams meetings and team chats can be associated with Microsoft Teams’ member profiles, such as Scrum Master, and Product Owners.

Enhance the Adherence to Agile Principles

12 Principles Behind the Agile Manifesto, and opportunities for rules to be trigger based on conversations, the interactive dialogs.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Dialog Intent Rules for Agile Guidance

From the above agile principles, we can derive the following dialog intents and precise recommendations for improvement.

Barriers to Implementation

At the current level of Artificial Intelligence (AI) Digital Assistants, i.e. chatbots, even the “best in breed”, has “difficulty”, i.e. lower probability with intent recognition, with a single sentence or phrase. Multiply that by interpreting an interactive dialog with multiple sentences, multiple participants, and exchange of responses, feasibility is highly speculative.

And Still More Opportunity: Recognition of Facial Emotional Expressions 

Expressions of people may be able to be determined, and opportunities for suggestive posture can be advised. Even body posture folded arms as an example, can imply a guarded opinion, and not open to compromise.

Reference article – Emotion recognition using facial expressions

Caution and Opportunities

This plugin output could be used for annual employee evaluations.

Azure DevOps 6 “Most Wanted” Features

Integration of SharePoint into Azure DevOps and Toss the Current Wiki

JIRA and Confluence a powerful combination. Microsoft should ditch the Wiki integrated into the Overview module, and use SharePoint (lite) instead. Put your best foot forward!

Backlog “Feature Timeline” Filtering

As I’ve mentioned in prior posts, the add on “Feature Timeline” by Microsoft is a fantastic bridge between Agile and Waterfall, displaying a Feature [i.e. Milestone] timeline. Expand upon this module with additional capabilities, such as filtering Features by Tags.

Microsoft Teams Chat mentions in Azure DevOps (ADO) Product Activity Feeds

I like trolling the Activity Feed on my Dashboard as much as the next person. Let’s add some external, yet related data sources, such as Microsoft Team Chats directly correlated ADO Team == Microsoft Team. Is that a setting, linking MS Azure DevOps Team to Microsoft Team? Should be…

Auto-generation of Release Notes After Each Build from Repos into the Azure DevOps Wiki

  • Similar to Java Doc, in line code comments roll up into C# Function doc
  • Commits Required to Specify Correlated Work Item IDs
  • Dynamic Wiki Page creation for each build, including release notes, unit test suite execution results

Ability to Create Azure DevOps Wiki pages from within Power Automate (i.e. MS Flow)

Shared Queries Segregated by Teams within the Project

Teams each have their own view of relevant Team information such as Dashboards per team

Runner Up Features

  1. Need the ability to re-name Azure DevOps Dashboards
  2. Need the ability to Clone Dashboards
  3. Product / Project / Portfolio Level Capacity Planning – 3rd party integration, OnePlan handles this requirement

The Power of Collective Consensus for Story Point Effort Estimations

Blind Concurrent Flip

The bartering of effort estimations between a team of 5 or more is really cool to witness and even further awesome to negotiate the consensus process. Not quite the process of the US Congress, but still attempting those on the periphery, extreme right or left of the bell curve of outliers to move toward the consensus. Discuss and draw near the point of consensus under which individuals discover their own need for resolution under grounds of somewhat tangible to their position of an item so complex gives one hope for a grander purpose.

A synonymous flip of the cards leading to the reveal moment is humbling when a team, after several rounds of dissonance, start into a pattern yielding the voting of a collective cohesion. Why do we start voting along a mutual agreement without the need for cohesion?

Can I Convince You to..

What if Chris Wallace facilitated a Planning Poker exercise between the two presidential candidates instead of a debate, driving consensus between the two presidential hopefuls?