Tuesday, October 20, 2020

Locating Uranus from Aries - Oct 2020

Locating Uranus from Aries with Binoculars and a little help from the planet Mars in light polluted skies (Oct 2020)

Locate the bright stars of Hamal, Sheratan and Mesarthim in Constellation Aries by looking to the left of a very bright Mars in evening skies.

From Mesarthim, locate Iota Arietis just to the right and then count down 5 lesser bright stars to locate 19 Arietis. If 19 Arietis is in the upper right of your binoculars, then Uranus should be somewhere in view in the lower left.…

See More
Image may contain: night, text that says 'Sheratan M74 Mesarthim 1 lota Arietis Mars 19 Arietis -Uranus 29 Arietis'
Like
Comment
Share

Wednesday, April 15, 2020

Implementing Innovative Ideas's: As an internet customer, I want my modem to be smart enough to auto-renew credentials so that I have reliable services

[The user story could also be versed from a developer's perspective as: "As a developer, I want the modem to be smart and renew its expiring credentials so that my time can be better utilized"]

In the middle of PI execution, a developer has an innovative idea to make the modem a smart device so that it knows when it's credentials/security certificate is expiring, it is aware that it will have connectivity issues.
The device can be made smart enough to reach out to an end server and says "hey, my credentials is expiring in a few months. I think I need to renew my credentials"
Assuming the end server has all the connectivity to the authentication servers and certificate authority, it can determine if the device is eligible for renewal and sends back a renewal.
The device receives the renewed credentials (maybe sends a thank you note (acknowledgement) to the end server and installs or updates the renewed credentials.

Assume the organization is using a scaled agility framework. Although estimates for implementing are provided in the PI planning, the team(s) focus on business objectives, intent and alignment around outcomes, then they may find that the actual implementation plan and process are not detailed in the PI Planning regardless of any pre-PI planning. The objective may be to 'get all modems renewed with updated credentials'. The business outcome would be to ensure the reliability of devices and ensuring device connectivity by automating credential renewals.

So the question comes up how were the feature estimates provided without the implementation plan? Assuming the feature estimate was based on top-down, historic info, nonetheless, the team also provides estimates that need to co-relate.

Feature estimates are usually top-down, refined and then co-related with user stories from bottom up. So for PI Planning an estimate is provided, an implementation plan is discussed across multiple supplier, manufacturers, and any other teams.
However, during the PI execution, a better more innovative idea arises in a developer or engineer.

So another question, does the team take it up with product management and business owners and re-look the implementation? The PI Planning board is expected to have laid out all dependencies (remember the red ribbons) so if one team is changing that another team has a dependency on it impacts all teams.
How would the idea be taken forward to get it implemented cross-supplier, cross-teams. Would the PM and Business owner be required to take the idea forward to all the teams?

Remember, teams have already submitted estimates for the PI objective and capacity planning is completed.

The best answer to the questions, may be Communicate! Communicate! Communicate! PO Sync, Scrum master sync, System demo's

Perhaps the best answer around estimation of user stories is to use generic sizing like t-shirts. How much of the work is uncertain, how complex, how many resources and then determine your Fibonacci based estimated based on size. Recall a user story follows 3C's - Card, Conversation, Commitment.

The actual acceptance criteria will get to be known only during the team's backlog refinement in iteration execution. Recall that acceptance criteria are the finer details of the implementation.



Note that SAFe is a copyright and trademark of scaled agile framework and more info can be found at http://www.scaledagileframework.com



Friday, March 27, 2020

Agile frameworks: Supporting "Maneuverability" of Agile Teams to support urgent last minute requirements vs "Tyranny of the Urgent"

After working on a large scale SAFe installation and observing the issues with the implementation, I came upon the understanding that for scaling agile, support for urgent last minute requirements is needed . I call it "Maneuverability" of Agile teams. And it means supporting just-in-time planning even right before the start of a n increment (such as SAFe PI) and even during a planning session (such as SAFe PI Planning) and even if it means shifting in/out of epics/user stories during an incremental delivery

Although frameworks like SAFe support uncommitted objectives or variability in a program increment, these objectives are still pre-defined and planned for although the outcomes are uncertain. Perhaps a certain capacity for variability or uncommitted objective needs to be added or planned in each PI to support urgent needs.

It helps to remember that  frameworks such as Scaled Agile usually have very definite requisites on team size, train size and processes. Nonetheless  one should be able to adapt it to one's needs. And seriously, even large corporations such as in the Aerospace or Telecom industries work with smaller suppliers to get services and these suppliers are often dedicated to multiple customers.  So to avoid the framework becoming another "tyrannical framework" with processes to be followed to the letter, the framework needs to support it's own adaptability. 

Hopefully in one of the future SAFe release (maybe SAFe 6), they will decide to include "maneuverability" or the ability of teams to maneuver some of the items they are working on to support the "urgent"
Although SAFe references "avoiding tyranny of the urgent", yet sometimes urgency is the nature of markets and business. If teams can swap out lower priority stories planned in the next incremental delivery and have frameworks that support ability for just in time planning for "urgent" user stories, then are they not being truly agile?