Tag Archives: Software Development

Software Development, Technology

“Must Have” Power Automate Enhancements for Solution Maturity

Leave a comment

My aspirations at commercializing “externally” facing, manually executed workflows using the MS Flow SDK are at an impasse. There are several key changes required to move forward, listed below.

In addition to removing my “Blockers” for leveraging the MS Flow SDK, I have a “wish list” below that contains features that would enhance the overall Power Automate solution.

“My Flows” Folder and Tag Hierarchy

I asked for this feature from Day #1 when MS Flow was released. Organizing your Flows within a flat, hierarchical structure is difficult. Users cannot create folders and organize their content.

Organizing Flows
  • The user should be able to create folders and put Flows in them.
  • Attach “Tags” to each of the Flows created. implement another view of “My Flows,” and group Flows based on Tags with the ability to show a single Flow within multiple Tag views.

Version Control

The user should have the ability to iterate saving workflows, compare versions of workflows, and revert to a previous workflow version.

Security Model Enhancements – Sharing Workflows

Implement execution permissions without the ability to manage or read any other workflow information. Introduce the concept of a two-tiered security model:

  • Admin user, the current view for all Power Automate users
  • Introduce a user profile/security group, execute only specific workflows where explicitly granted permissions to a Flow.
  • Eliminate the need for another Power Automate account only being used for shared workflows to execute.
  • You should only need one account with a Premium Connector $ license if only using the secondary account for execution.

Development, SDLC, Work

Great Tips for DevOps Teams Running on Kanban

Leave a comment

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.

Agile, Architecture, Software Development, Technology

Agile Adoption Challenges: Outside the Circle of Trust

Leave a comment
  • Outside the Product Owner and the implementation team, senior stakeholders may require milestones articulating deliverables.
    • Epics or Themes, high-level declaration of the “Release” essence, rolls up from Features, and Product Backlog Items (PBI). Relative effort estimations may be applied at the PBI level, and then rolled up to calculate/guestimate the duration of Epics.
    • Look toward SAFe (Scaled Agile Framework) to change the culture by providing an opportunity for the entire organization to participate in the Agile process. “Product Increments” present windows of opportunity every 8 to 10 weeks.
    • Product Increments may involve multiple scrum teams, their scope, and how these teams may intersect. In order to synchronize these Scrum Teams, SAFe introduces Agile Release Trains (ART), and Release Train Engineers (RTE) to coordinate cadence of the scrum teams to be in alignment with Epic and Feature deliverables.
  • Stakeholders may require a “waterfall” plan to understand delivery timeframes for milestone artifact deliverables. For example, “When do we deliver in the plan? We have dependencies on XYZ to build upon and integrate”
    • External teams may have dependencies on artifacts delivered in the plan thus cross scrum team interaction is critical, sometimes through a reoccurring ceremony “Scrum of Scrums“.
  • Additional transparency into the scrum team or the “Circle of Trust” can be provided through the use of Dashboards. Dashboards may contain widgets that produce real-time views into the current initiative. Key Project Indicators (KPIs), metrics being monitored to determine the success of Product ABC Epic Phase completion.
    • Dashboards may include: Average Team Velocity, Burn Down, Burn Up, Bug Status by Severity, and metrics that are initiative focused, e.g. N out of Y BI Reports have been completed.

AI, Artificial Intelligence, Machine Learning, Software Development, Technology

Deep Learning vs Machine Learning – Overview & Differences – Morioh

Leave a comment

Machine learning and deep learning are two subsets of artificial intelligence which have garnered a lot of attention over the past two years. If you’re here looking to understand both the terms in the simplest way possible, there’s no better place to be..
— Read on morioh.com/p/78e1357f65b0

Agile, Business, Development, Project Management, SDLC, Technology

Agile Manifesto – Personal Reflection

Leave a comment

Individuals and Interactions over Process and Tools

Stereotypical software developers are introverts, heads down, coding. Articulating where they are in the development lifecycle sometimes heavily relies upon tools for measuring progress such as JIRA, Product Backlog status of User Stories, e.g. “In Progress” with an Effort estimation of 3.

“Blocked” User Stories may require the implementation team to “break out of their shell” and work with their teammates to “unblock” Product Backlog items. It breaks people out of their comfort zone. We need to discuss options and opportunities for removing blockers. “All for One, and One for all”

Working Product over Comprehensive Documentation

Over a decade or so ago, the measure of my merit was the complete test coverage of requirements for software implementation. Back then I was a QA lead, and my focus was to make sure all use cases for the software under development had complete test coverage.

Requirements changes from our business through our business analysts must be vetted with the QA team so use cases/test cases must be updated to ensure coverage. Sometimes a dependency of one requirement had a ripple effect throughout the software, so lots of documentation updates were required. Milestone dates were in many cases fixed, so teams were squeezed to do more with less time.

Flash forward to today, and leveraging Agile principles, I breathe a slight sigh of relief. Iterating product delivery via sprints every 2 weeks is supremely better than attempting to traverse updates to Business Requirements Documents (BRD), and technical specs. User Stories in a Backlog are much more succinct, and in some cases, a bit more abstract leaving functionality open to some level of ambiguity and interpretation.

Sprint Close scrum ceremonies every two weeks with our Product Owner, the central mouthpiece for the definition of the software product helps define the path forward. Did we get it right? Where do we need to make changes? There is no substitute for an evolving product and accompanying dialog with our Product Owner.

Customer Collaboration over Contract Negotiation

Both sides of the aisle seem to agree, building a solution with iterative input from the customer enables the product vision to be realized far better than without frequent touchpoints.

Statements of Work (SoW) to engage 3rd party solutions integrators (SI) may be abstract in some way. Holding vendors accountable for loosely formed requirements is tenuous at best. Quibbling about he said, she said is a waste of time.

Fail fast, engage regularly and often with our [Business] Product Owner enables us to collaborate on a working solution. The focus is on the evolving product vision and not the paper trail.

Responding to Change over Following a Plan

A “last-minute” change request? It could push back our timelines and accompanying milestones. Dates can’t change, and teams need to absorb the changes, i.e. nights and weekends. Responding to incremental changes at a regular cadence is a sustainable life cycle.

Agile, Business, Development, Software Development, Technology, Work

Agile’s Watergate

2 Comments

A relic of the Waterfall model is the construct of a “gate” process. In order for a project to achieve a milestone, the project/solution would need to achieve certain criteria that would allow it to go to the next phase of the project. For example, going from solidifying requirements in a Business Requirements Doc (BRD) to the software implementation phase.

In Agile, we leverage the Product Owner (PO) and the Product Backlog to determine what gets done and when. A Product Backlog item (PBI) may cover the full lifecycle of a Feature, from requirements to implementation. The Product Owner dictates acceptance of the PBI based on the status/transparency of the Backlog, such as the criticality of the Bugs linked to the PBI. Product quality and implemented functionality are transparent to the PO, who will determine the next steps such as release the software, and/or go through another iteration/sprint. Iterations are a defined cadence agreed to by the implementation team and the Product owner, typically, 2-week sprints.

Agile, Hybrid Environments: Opportunities for Synergy

Epics, Features, Product Backlog Items, and Tasks are object types in a Backlog that enable the PO and the team to link objects and plan over multiple sprints. Epics or Themes of Sprints are “high level”, potentially strategic initiatives. Features roll up into Epics as a part of several sprints. Either Epics or Features may be high enough level to link to Psydo Project Milestones for a product roadmap of deliverables, and solicitation outside the team.

Aggregation of Product Backlog Items, Effort Estimations, roll up into Features, and then up into Epics, which roughly equate to milestone timelines.

The “Definition of Done” (DoD) for a Product Backlog Item may require 0 outstanding Bugs with the severity of “Critical” linked to this PBI. The DoD criteria could be analogous to a traditional Quality Assurance gate.

Tasks that are production rollout activities, without a project plan, should be planned for in future sprints, akin to estimating when items may be completed in the proper sequence. Some of the Tasks may be placed conservatively in “early” sprints and may require items to be “pushed forward” after each of the iterations.

Agile, Project Management

Agile Mind Games – the Psychology of Scrum

Leave a comment

Team Effort Estimations Are Critical to Accurate Velocity, Maximum Productivity, and Team Building.

The team tech lead may provide an effort estimation with little or no input from the developers and/or testers doing the work.

If the tech lead vocalizes his/her effort estimation…

  • BEFORE the developer who will be doing the work, the developer may feel pressured to agree with the tech lead’s estimate.
  • lower than the developer’s guestimate, who will be doing the work, this might create social friction and inaccurate velocity.
  • WITHOUT a collaborative approach, a comprehensive estimation may be ruled out, such as consideration for not only dev. and test., but infra (configuration management, i.e. build & deploy) and other effort costs.

Using tools like Planning Poker, where all estimations are revealed at once helps the team appear to not contradict one another. The negotiation process occurs after all teammates flip their cards at once. Derives better estimates with more perspectives not factored in based on a single Tech lead providing the estimation.

Transparency and Scrutiny

Many “hands-on” project/product stakeholders want maximum transparency into the current state of the product regardless of the duration of the sprint (e.g. 2-week sprints),   Typically, a pulse on the product at two-week increments satisfy most.

Some of the agile, change management tools such as Microsoft Azure DevOps offer dynamic graphing and reporting.  Product stakeholders may be provided dynamic dashboards, that include Burn Down, and Burn Up charts based on the sum of effort from user stories (i.e. product backlog items).  At any given time charts can predict velocity, and based upon the outstanding, total effort estimation, can chart a course to the next release.

Meaningful burn up and burn down charts rely not just on accurate effort estimations, but the people who are assigned these user stories constantly update the status of these stories, e.g. New; In-Progress; In-Review; Done. Countless times I’ve seen team members update the user story status the day before the sprint close/demo, from New -> Done.  This habit gives any product stakeholders a false view of the product within a sprint.

Another challenge and opportunity with Transparency and Scrutiny within a given sprint, is making sure each user story has one or more (child) tasks.  Defining tasks provides a wealth of opportunity, such as naming all of the tasks to complete for the story, e.g. database tasks, UI tasks, etc.  If the tasks are itemized, they may also be assigned to multiple team resources, and show a delineation of labor.

Sticking with the Azure DevOps tool, Tasks have a default field, “Remaining Work”.  This field may express task work in hours or days, the unit of measure. In the beginning, tasks are populated with the total task guesstimate of hours. Each day the person assigned the story task may draw down on the task to incrementally show progress within the task and correlating story.

Task, Work Remaining field must be relentlessly updated across the Backlog in play or else it will create more harm than good. At this level of scrutiny on tasks are amorphous and will be challenging to garnish any projected value.

The Abominable Blocker

What, you can’t figure it out on your own?

The dreaded blocker has the ability to stop a Scrum team in its tracks. The term Impediment used synonymously with the word Blocker, has an innocuous sounding sentiment. Your Scrum team may use either, perhaps a less severe issue merits an Impediment?

The Kanban / Scrum board may have a column in the workflow called Blocker, which should fixate your team on helping to remediate that Blocker. Our Daily Scrum of 15 min may focus on Blockers as they have been isolated in our workflows.

Conquer the blocker before it conquers you!

Applause, Applause

Closing and Demo for Sprints should follow healthy applause from the team, including Stakeholders and Product Owner. Positive reinforcement of a job well done. We’ve completed what we committed to complete, should be followed by applause. We should take a moment to soak in the feedback.

Pass the Mic

For those of us on the Scrum team who are introverts and actively look for ways of dodging opportunities to speak, this one is for you. During Daily Scrum, pass the facilitation mic around where everyone gets an opportunity to facilitate per stand up.

Allow all people within the team an opportunity to demo the “Done” user stories on sprint close. It’s not to break folks out of their shell, it’s to impart a sense of pride in the work accomplished, and truly resonate the one team mentality.

Disclosure: the opinions provided are my own and do not reflect that of my clients, or anyone I represent.

SDLC, Software Development, Technology

Seven Interview Screening Questions for an Agile, Project Manager

Leave a comment

It seems like only yesterday… I was on the other side of the table, asking interview screening questions to perspective project manager candidates.  Here are seven interview screening questions I was asked earlier this week for an Agile, PM role, and my answers.

Background:

I’d consider myself an Agile Project Manager rather than a Scrum Master.  Differentiation?  I see the Scrum Master role as a coach / facilitator to help the team function using the Agile / Scrum methodologies.    The agile PM role, in my mind, does the coaching/facilitation as well as filling the traditional role as the PM.

Questions:

1.  What is the duration of the Sprint Cycle?

On scrum teams I’ve lead and been apart of in other capacities, its ranged from 1 to 2 weeks, but mostly two week sprints. In one instance, we had two week sprints, and then just after our major release to our client, we set the sprint to one week duration so we could incorporate client feedback ASAP.

2.  What are the various Agile ceremonies you conduct from day one to the last day of the sprint?

Project Kickoff – not necessarily limited to Agile, but is a project ceremony to get the team acquainted with roles and responsibilities, understanding scope at a high level, and the overall project duration expectations.

Initial Combing the Backlog with the Product Owner, and Tech lead(s) to identify priority backlog stories, and technical dependencies for the initial sprint(s), potentially looking ahead to 1+ sprints

Sprint Open #1 (all matrixed team members partake) In this meeting there are a number of activities that may occur:

  • Reviewing the Backlogwith the team in business priority sequence.  Fleshing out the user stories’ definitions, where required, enough to score each story
  • For each User Story in the Backlog prioritized for the current sprint, the team mayperform an efforting exercise to derive the ‘story points’. Playing Planning Poker is one way to derive story point estimates
  • Each of the story point estimates adds up to determine the potential velocity for the sprint, or team output potential
  • User stories assigned to the current Sprint are ‘Accepted’by the team for implementation in the first sprint, and are assigned to team members. e.g. for coding, doc, infra, or additional vetting, such as Architectural Spike stories.
  • Product Owner, Project + Technical Lead(s) decide beforehand how long sprints will take, and roughly thepotential velocity of the team based on all story points in the Sprint.
  • Sprint Open will commence, and any tool used, e.g. JIRA Agile, will enable the Agile PM / Scrum Master toinitiate the Sprint in the SCRUM / Kanban board.  All user stories are set to an initial state, e.g. “To Do”.

Agile Ceremonies Continued…

DSUs, Daily Standups, or Scrum sessions.  Traditionally, 15 minute sessions primarily to uncover BLOCKERS, and help each of the team members to remove their blockers.  Also, discussed, work from prior DSU, and current work until next DSU

(Optional) At the ending of each sprint, a day before Sprint Close, a Retrospective meeting is held, i.e. what did the team do well. what can they do better

Combing of the backlog for the next Sprint with the Product Owner, and Team Lead(s) e.g. re-evaluate priorities; e.g. 2 uncovered additional Stories / Tasks required for Sprint #2

Sprint Close #1 / Sprint Open #2 – Many times Sprint Close, and Sprint Open are combined, or may be separated depending upon the scope of the sprints.  I’ve sat through 4-5-hour Sprint Close sessions.  The Sprint Close may have each of the stories marked as status ‘Done’ reviewed by the team including the Business Product Owner.  A demonstration of the User Story, if applicable, may be performed, e.g. a new button function.  The team demo may occur by anyone on the project team.  The product owner may be required to move the status of the user story to ‘Accepted’ as a final status.  Additionally, burn down charts, and other visual aids may be provided to the team to uncover the team’s projected velocity on par with actual results, and lead to projected effort adjustments.

Sprint Open #2, similar activities to Sprint Open #1.  Team will see what stories they planned to complete, but did not.  Should the team push these stories to the next sprint, or to the backlog for future implementation.

Each sprint in the strictest sense, the content delivered should be ‘deployable’, a commitment to release work into target environments (e.g. Staging, Prod)

3.  When a project starts, how do you figure out the project scope?

Some projects with ‘external’ clients have a clear definition of project scope in the statement of work (SOW).  Other times a Product Owner may have a list of items solicited from product stakeholders.   These are two possible inputs to the ‘Product Backlog’ maintained in any Agile/Scrum facilitation tool, such as JIRA Agile, or Microsoft’s Team Foundation Server (TFS).

Combing the Backlog with the product owner, and tech leads may enable the team to add more details / definition to each of the User Stories in the Backlog.  In some cases, team leads may assign user stories to an Architect or Developer for the purpose of refining scope, and adding ‘sub-tasks’ to the user story.    In addition, some project scope needs to be defined and refined through ‘Architectural Spike Sessions’.

4.  If a Scrum Master is [managing] multiple projects, do they follow the same process for each project?

It helps if a consistent process is followed across scrum projects to eliminate confusion, and potential work across projects.  However, following a consistent process is not required, and there may be business or technical reasons to alter process.

5.  What kind of reports do you create in your Agile projects? Explain the reports.

Burn down chart – line chart representing work left to do vs. time.  Helps to understand if the team will achieve its projected work goals; shows the actual and estimated amount of work to be done

Velocity chart – bar chart (per sprint) showing two grouped bars, one for commitment, and the second for completed.

6. If you have a team resistant to Agile, and are saying there are too many meetings and the process is micro managing the effort, how will you resolve this and convince them to use Agile?

Be on “their” side: “I agree, our daily standups should be all about blockers” How can we remove your blockers inhibiting your work.  “Sprint Open” is a vehicle to clarity on work to be done, and a quick turnaround time during “Sprint Close” are we delivering what the product owner is looking to achieve?  Keeps us focused on what is committed to by the team.

7.  How do you figure out the capacity of a project?

“Capacity of a project” is a ambiguous statement.  If you want to understand what can the team achieve within a given period of time, you establish (sometimes through trial and error) and verify the velocity of the team, how many points they can roughly achieve for a sprint.  Create buckets, or sprints from the backlog work, effort the user stories sprints, and an estimate is derived.  With each sprint, those estimates will be refined with a better understanding of scope and velocity.

Content from this post provided by Ian Roseman, PMP, CSM