Category Archives: Development

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.

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?

Agile Manifesto – Personal Reflection

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’s Watergate

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.

When Stakeholders Collide

Requirements Expedition

Maybe you’ll meet them during the Project Kickoff. Maybe you’ll first hear from them during a biweekly Steering Committee. Or maybe you will first hear from them three months into the project at a quarterly meeting with the CIO and the rest of his portfolio. Maybe you will never hear from them directly.

The politics of requirements gathering and prioritization is a daunting process. I’m not going to drudge up all the stories and categorize them here because it’s a painful process.

Why are some of your milestones in your project plan:

• the milestone exists within someone’s year end evaluation

• the requirements of a milestone are so bipolar, they are bound to fail. Need a project to bucket the requirements to say “we tried”, and we can pin it to a project.

• backing into established project timelines based on expectations set at the highest levels, e.g. regulatory compliance

Legal and Compliance Stakeholders

Global representation of legal and compliance requirements are a dichotomy of legal precedence between jurisdictions.

Agile Product Owner verse Waterfall Stakeholder Committee(s)

Many a project managed using waterfall kept me balancing the needs and wants of Stakeholders from all walks of life, some exuberantly voicing their opinions regardless of their position of power, or lack therein. The Agile Product Owner (PO) is a relief of burden, a single mouthpiece of the business, which dictates backlog priority.

Does Agile make the requirements gathering and prioritization pain go away? Possibly. There are various implementations of Agile, hybrid situations, and there are lots of tools out there to help manage the Product Backlog (requirements). Another exercise, developing User Journeys, working with your Personas / actors to derive their story, that is telling and lots of fun.

7 Failures I Needed to Succeed

Here is a list of seven failures from my professional career, how I met those challenges, and in some cases, turned them into opportunities

Underestimate

Eager to please throughout my career, I was burned many times, and in some cases continue to be burned by underestimating the effort required for an activity, or task, which roll up to the delivery of features, or meeting a milestone. In my earlier years, I “shot from the hip” to senior management, and they held me to those commitments. Over the years, I’ve been fortunate enough to document and mitigate risks. In addition I learned additional tools, both process and communication / people skills:

* “Interesting point, let me consider, and get back to you.” You don’t have to provide an answer right away. Consider the scope and impact of the questions you are presented. Unless you are almost certain of the answer, try to defer.

* Planning Poker (Agile) collaborative (blind) estimates make better estimations. Through collaboration, you reach joint commitment. You eliminate the “boss knows best” factor.

Hearing but not Listening

Throughout my personal and professional life, I’ve struggled with this aspect of communication, more so earlier on in my life. Two people have a meeting, and discuss their point of views regarding the same topic. They both leave the room, and have two polar opposite prospectives of what was communicated.

Even in the same language, things get “lost in the translation.“. There are many process tools to better your communications style. You hear what you want to hear. You don’t probe deep enough into another person’s perspective.

Overestimate

Adding too much margin into an estimate, being conservative in your effort estimate at times may not be the best course of action. “Right Sizing” the estimate is typically the desired approach unless otherwise guided by the appropriate stakeholders. There are lots of tools for Effort estimation, poker planning, and fist of five are just two examples.

Army of One – Embrace Opportunity

I was brought into a development team as a Software Quality Assurance manager for a well known Financial Services organization. I was to build a team of QA staff as well as mature their process workflow, e.g. implement software change management.

The department’s QA resources per team dwindled, letting go these resources, and not growing the teams as first advertised during the interviews. I found myself constantly working with the team putting out fires. Best case scenario, I worked “after” hours just to work on the strategic stuff like process improvements, and automation. I stuck to the opportunity to learn as much as possible. Sticking with the job, I built my knowledge and relationships that would wind up propelling my career to later on build and manage a 50 person, global team.

Build it and they will Come…Bull!

I chose to try my own startup at some point in my professional career. I had worked for a startup firm out of college, but that was not the same as my own self startup. There were lots of balls to juggle, decisions to make and prioritize. After a year and a half, I shutdown the company, more money going out than in, and I was also “relatively” self funded.

One of the several ill choices I made was “Build it and They will Come.” At the time it was 2009, and the mobile frenzy was just starting to heat up. Feb 2009, Apple was at 30 USD per share! 30! I built a client/server mobile application for expertise transactions, way ahead of my time. I was almost entirely focused on the development of the solution, I clearly lost sight of the focused requirement of building market share. I did post Press Releases, but I didn’t embrace digital marketing as a core spend and activity for my business.

Needless to say I was “The Best Kept Secret”.

Chasing the Sun

As a software product, startup firm, you need to segment your product to align to a target audience. However, honing in on the target market maybe problematic if the “fish aren’t biting”.

You find yourself reassessing the strategic and tactical goals of your product, pivoting often to eventually find your “pay dirt”. There may be fundamental influences to your ecosystem, such as a shift in a 3rd party product previously seen as complementary now seen as “overlapping”. Sales pitch and marketing approach may need to change along with your product.

Although pivoting often may be the name of the game, you still should recognize the cost in adapting to change. Process flows like being “agile” and Scrum help to smooth the pivot, as these processes revolve around constant development iterations and reflections every few weeks.

Time to Pull the Parachute Cord

I still have trouble with knowing when it’s time to say when. I enjoy troubleshooting problems, business, people, process, and technical. So, how long do you work on problem before you pull the ripcord?

When and How to Create Journey Maps

Journey Maps are excellent as a tool for deriving requirements, as well as better understanding the customer.  Similar to a paper-based, use case process to understand an “Actor” on their business workflow, journey maps visualize the customer/user experiences.  The article below is a primer to the creation and usage of a Journey Map.

Summary: Journey maps combine two powerful instruments—storytelling and visualization—in order to help teams understand and address customer needs. While maps take a wide variety of forms depending on context and business goals, certain elements are generally included, and there are underlying guidelines to follow that help them be the most successful.

What Is a Customer Journey Map?
In its most basic form, journey mapping starts by compiling a series of user goals and actions into a timeline skeleton. Next, the skeleton is fleshed out with user thoughts and emotions in order to create a narrative. Finally, that narrative is condensed into a visualization used to communicate insights that will inform design processes.

Source: When and How to Create Customer Journey Maps