- 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.
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
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.
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.
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!
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.
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.
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.
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
At the 2013 Computer Electronics Show, there were only a few vendors touting Near Field Communications (NFC) technology integrated into their products, that I could see, and I did try to get to as many booths as possible. Last week I mentioned people in Korea use NFC business cards to exchange and play music on their devices. After that post, I did see a company’s tweet saying they were going to get into the distribution of NFC cards to store music, movies, and more, as the advertisement stated. The benefits of this technology over Bluetooth simply low / near null power signature, inexpensive relative to the Bluetooth technology, and the potential shortcoming is it has a very short range. Smartphones equipped with NFC can be paired with NFC tags or stickers which can be programmed by NFC apps to automate tasks. NFC always involves an initiator and a target; the initiator actively generates an RF field that can power a passive target. This enables NFC targets to take very simple form factors such as tags, stickers, key fobs, or cards that do not require batteries. NFC peer-to-peer communication is possible, provided both devices are powered. NFC tags contain data and are typically read-only, but may be rewriteable. I also had a conversation with someone that implied the storage on the NFC tags may be limited, so an easy workaround would be to store unique keys, such as a reverse domain name, and other pointers to data in a structured storage data web cloud, which is hosted by any number of verticals.
In this post I wanted to highlight a few potential uses. Unfortunately, this is the second time I am writing the blog post because the first one didn’t get saved. Annoying!
Instead of the sticker a car dealer, or your mechanic, may put in the top left hand corner of your window to remind you to change your oil at N miles or Z months, an NFC sticker can be encrypted with your car’s VIN number, the complete required and suggested maintenance for the vehicle, as well as when and by who these services were completed. The NFC Sticker may be placed in the console where you might place your smartphone.
Food Storage, Food Savings
On your refrigerator, you may place an NFC Sticker, that is overlaid on a magnet. Every time food is removed or placed in a refrigerator or pantry, you can swipe the food NFC tagged with the cooperation of the food manufacturer. An average usage model can be derived and encoded on the tag, as well as a proximity timer. If the food item, such as milk, is not returned to refregerator within a given period of time, a notification on your smartphone, and/or a depreciation counter can be reprogrammed on the NFC tag to indicate approximate usage. Once the item needs to be restocked, or placed back, a notification may appear on your smartphone, and/or added to your shopping list.
Books, Music, and Movie Samplings from a Store
If you’re in a store, and pass by a book, music CD or movie DVD, an NFC tag may contain a URL to download a PDF sample of the book, a music track from the CD, only available in stores through use of the NFC tag, or bonus material from a movie that only can be accessed through the NFC tag in stores to drive traffic into a store. I specified a URL to link to the content because the current specification seems to limit the amount of storage on the NFC tag, however, specs can change, and I might be a bit conservative on the amount of storage necessary, but with a ‘secure cloud’, the storage shouldn’t be a factor. Any information on the NFC tag can simply be pointers to unique keys to data in tables within the cloud, such as a VIN number, or other generated unique keys.
Imagine your in a store by yourself, and trying on an article of clothing, if the dress, pants or skirt contains an NFC tag, you can touch it with your smartphone, which links you to either advisors or AI, perhaps sponsored by a fashion magazine, that may provide you with with ideas to match that article of clothing, such as complementary accessories. This could be accomplished through a video camera, front facing camera, perhaps ads float across the bottom of the screen, and/or it could be a subscription service.
Meeting People / Dating
If you find yourself in a crowed bar, or party, and want to exchange information with someone you just met, you have an NFC tag or sticker placed on the back of your hand, or on your purse, when bumped, will automatically exchange a brief bio, picture, likes, interests, and an email address. If your smartphone is GPS compatible, the data is loaded onto your smartphone with the captured NFC tag data in addition to the location, so you never ask, so where did I meet this guy again?
Supply Chain Management and Shortages
Every person in the supply chain from manufacturer to retailers may have an NFC tag embedded within their employee identification tag, and as each individual handles the product or package, they swipe their card to the other NFC tag, and their employee unique identifier, along with date time and location (optional) may be rewrite the tag to append the new information. This may prevent product shortages, as well as help further optimize the supply chain.
Today I spoke with a Development System Engineer from the Ford SYNC AppLink Team at the Consumer Electronics Show (CES), and he was extremely enthusiastic about their launch of their API which enables developers of Android and iOS mobile applications to use the SYNC AppLink SDK APIs so a developer may take advantage of SYNC through your mobile device. The SYNC AppLink software development kit (SDK) the software engineer admitted that the library was relatively limited to roughly 50 API calls (estimate off the cuff), however, they are constantly looking to expand the SDK. They are recommending utilizing the Voice Recognition API as an example.
As I explored the conversation with this System Engineer / Developer, I tossed a few ideas, and wanted to see the direction of the team. I suggested expanding the SYNC technology to link the system to measuring tire air pressure, fuel, oil, and other liquids, as well as ‘by the book’ scheduled maintenance, air filtration quality, and so on. Then the SYNC AppLink team would expose these functions through the SDK, so that mobile application developers can create applications from dashboards, which sync with the phone through Bluetooth automatically every time the user gets in the car, and has an up to date check of their whole car health and maintenance in or out of the vehicle. There are endless opportunities, such as mobile notifications on low fuel, maintenance, and even may enter a reminder in a task list named after your car, e.g. need 60 thousand mile maintenance, and oil quality poor, must change oil.
There were some potential limitations such as the display of the SYNC system, the SYNC AppLink Development team try to steer clear from distracting the user by exposing the APIs which may allow the mobile development users to modify the graphical user interface, e.g. flashing menus, which may distract the user, and may cause an accident, which would potentially have liability concerns. At most, they are looking to allow mobile application developers using the SYNC AppLink SDK to push smartphone pictures to an image frame, so you can see your phone pictures. However, in my humble opinion, there may be significant opportunities, such as a sexier, and more accurate equalizer controls. At last, we have the ability for SYNC AppLink SDK developers in the future to access information from your phone, such as calendar, stocks, tasks, and use the car sound system and SYNC microphone to add, hear, delete, and subtract any information from your mobile device.
I walked down the isle to another company, chargepoint, which manufactures charging stations, which are reasonably priced for stations at 5 to 10 thousand USD. This is a system which is rugged and can endure outdoor conditions. If we take the SYNC technology and integrate it into a Ford Hybrid & Electric Vehicle to analyze electric usage and be able to maximize your electrical charge. Chargepoint happens to also have an the ability to have an affinity card. That is for another post. There are quite a few stories, and it is still early in the week. Looking for the diamonds in the rough.
One note, although Ford went after Google Android and iOS first because of market share, you can be sure, Windows Mobile 8 is not far behind.