Tag Archives: SDLC

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.

Seven Interview Screening Questions for an Agile, Project Manager

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