SVP Technology at Fiserv; large scale system architecture/infrastructure, tech geek, reading, learning, hiking, GeoCaching, ham radio, married, kids
13761 stories
·
101 followers

How the 8086 processor's microcode engine works

1 Share
Comments
Read the whole story
JayM
6 minutes ago
reply
Atlanta, GA
Share this story
Delete

Macmillan Extends Remote Work

1 Share

Macmillan has extended its “hybrid & remote-friendly” policy through the end of 2023, allowing employees who can do their jobs remotely to “have the flexibility to choose the number of days per week they work in the office, or choose to work fully remotely.”

Jon Yaged, CEO, says,

Two things are clear: people want flexibility and we continue to live in uncertain times. So, we’ll continue what has been working ...Read More

Read the whole story
JayM
8 minutes ago
reply
Atlanta, GA
Share this story
Delete

Bettercap – Swiss Army Knife for 802.11, BLE, IPv4 and IPv6 Networks

1 Comment
Comments
Read the whole story
JayM
2 hours ago
reply
Useful.
Atlanta, GA
Share this story
Delete

$7M lost on Amazon inventory, then bankrupt

1 Comment
Comments
Read the whole story
JayM
8 hours ago
reply
Wow. Remind me never to become an Amazon seller. Lots of mess to clean up by Amazon it sounds like.
Atlanta, GA
Share this story
Delete

Breaking: Police are terrible at their jobs.

jwz
2 Shares
Denver police in SWAT gear raided Johnson's Montbello home looking for a stolen cellphone that had pinged in the area.

Johnson, in her bathrobe, opened her door when an officer on a bullhorn told anyone inside to come out. Officers carrying rifles stood on her lawn next to an armored tactical vehicle. One officer held the leash of a German shepherd K9.

Once inside her home, Johnson said, they smashed a door to her garage with a battering ram, broke apart a ceiling panel, broke the head off of a beloved collectible doll and left the house in disarray. [...]

The search warrant followed a report of a truck stolen from a Denver hotel. The owner of the truck said there were five handguns, a rifle, two drones, $4,000 in cash and an iPhone in the vehicle when it was stolen [...]

The following day the truck owner told Staab that he used the Apple "Find My iPhone" app [...] The truck owner rented a car and drove by Johnson's house and told Staab that he didn't see his truck but it could be in the garage. [...]

The search warrant never should have been approved, according to Johnson's lawsuit. Staab never tried to corroborate the truck owner's findings and never conducted an independent investigation before filing the request, the lawsuit states. The "Find My iPhone" app gives an approximate location and is not meant to be a law enforcement tool. [...]

"The screenshot offered no basis to believe McDaniel's iPhone was likely to be inside Ms. Johnson's house, rather than on any of several neighbors' properties, or discarded on a nearby street by a passing driver," the lawsuit states. [...]

The police department did not pay Johnson anything to repair the damage to her home, said Greg Brunson, Johnson's son. The family and their friends sent numerous emails to the department in the months after the incident asking for an apology but never received one, he said. [...]

The investigation into the stolen truck remains open and nobody has been arrested, Denver police spokesman Doug Schepman said.

Previously, previously, previously, previously, previously, previously, previously.

Read the whole story
JayM
19 hours ago
reply
Atlanta, GA
Share this story
Delete

Maximizing the Value of Your Agile Transformation - Scrum, Kanban, and Doing SAFe Safely

1 Share

In my final installment of this blog series, I discuss the mechanics of different Agile frameworks, how they work, and why they function better for different types of work intake. This article builds on the previous blog entries, so if you have not done so already, I would suggest reading the series from the beginning, starting with The Business Value of Agile, followed by Recognizing Agile Antipatterns, and finally Transforming All Levels of the Organization. These previous entries provide context for how the organization benefits from Agile, and what actions are required for an organization to get the full benefit of the Transformation. This context will better help the reader understand why the frameworks are built the way they are and the value that comes from successful implementation.

Choosing a Framework

If you are an Agilist in a company, and you have been assigned to a brand-new team, part of chartering that team involves helping the team choose an Agile framework to operate within. There are two things that a team must consider when selecting a framework to use:

  • Work intake predictability. Is there a product roadmap? Would it be fair to say that the team will have a sense of what they will be working on and where the work will be coming from? Or is this more of a service-oriented team, where the team has been chartered to respond and resolve requests coming from people or systems on demand?
  • Solution predictability. Is the work that the team receives fairly repeatable, or does it require significant discovery work and is usually a one-off endeavor?

There is a myriad of frameworks in the industry that a team can choose from, but I am going to focus on Scrum and Kanban for the purposes of this article, as they are the most widely used by far. Broadly speaking, both of these frameworks can be used by any team regardless of the type of work they do; there is no hard-and-fast rule that says you must use one or the other, but they do offer more or less benefit based on the above criteria. In general, Scrum tends to work better for teams that have a predictable work intake and non-repeatable solutions. Teams like this might be software feature development teams, teams implementing new programs or standards in an organization, or teams building experimental vehicles. Kanban is usually more effective for an unpredictable work intake, where solutions are more repeatable. Teams that benefit the most from Kanban tend to be teams that perform activities such as system performance monitoring, customer support, network device lifecycle management, or manufacturing.

The industry is saturated with resources describing what Scrum and Kanban are, so I will be focusing less on explaining what the artifacts of these frameworks are and more on the way that these frameworks deliver the kind of value described in my previous entries.

Scrum

Let’s say you work with a team that has chosen to implement Scrum, since they do a lot of project work where their work intake has a well-ordered backlog but the outcome of the work is uncertain. In the case of Scrum, the mission of the team is to deliver the highest possible value to the business at a sustainable pace. Since this work usually involves brand-new features that are being developed to solve a need, feedback loops are required to make sure that the work being done is actually solving that need in the best way.

At its heart, Agile is about inspection and adaptation with the purpose of achieving the maximum value for the investment. This value is realized by pivoting when needed, just as the McVickers pivoted from making wallpaper cleaner to making Play-Doh based on shifting market needs, as described in my entry on the Business Value of Agile. The feedback loops of Scrum are based upon two cadences: the Sprint, and the day. In Scrum, a “Sprint” is a predefined timebox that the team has to complete their stated goals. At the beginning of the Sprint, the team will plan to do certain activities based on statements of customer need called “user stories.” These user stories contain the persona that the feature is being built for, what the feature is, and the reason or value that the outcome of that development will deliver. This ceremony initiates two feedback loops: inspection/adaptation of the product being built, and inspection/adaptation of the way that the team is building it. After the team has completed their Sprint of work, two events take place. The first event is the closing of the feedback loop of the product. This is called a Sprint Review, and is a chance for the team to demo to stakeholders, receive stakeholder feedback, and change the scope of their product backlog based on that feedback. After the Sprint Review, the Sprint Retrospective occurs based on a reflection of how the Sprint went, and how the team wants to inspect and adapt on the way that they work. The Retrospective closes the feedback loop of the process.

The daily feedback loop both starts and ends with the daily standup. This standup meeting allows the team to plan for the day, and make sure they are getting out of each other’s way, not doing duplicate work, and ensuring that each team member is not blocked from delivering on the Sprint commitments.

An example of this might be a team that starts to build out a user story such as “As an open source application developer, I would like an API endpoint that accepts data fields A, B, and C, so that I can integrate my application with your system, and my customers are able to use your functionality, thereby generating more app sales.” After refining this story, the team goes into planning and figures out how they are going to go about building this endpoint. They work on the functionality throughout the Sprint, syncing daily to ensure that they are not blocked from progress, and finally demo to the stakeholder in the Sprint Review. The stakeholder says that this endpoint is exactly what they were looking for, but it doesn’t look like there’s validation in place to make the inputs numeric-only. The stakeholder then requests if the team might be able to implement this functionality. The team says absolutely, we can create another story and work on it in a future Sprint. The product backlog is altered to reflect this new priority, and the Review ends. The stakeholders leave, and the Retrospective begins. The team then asks questions such as “Could we have anticipated, somehow, that numeric-only fields was going to be a requirement? Also, I noticed that a couple team members worked late on a couple days this Sprint to get this done. How can we keep this from happening in the future? Did we underestimate, or misunderstand the story?”

Scrum operates on the philosophy that it’s much cheaper, easier, and valuable to pivot an endeavor frequently as needed. In fact, the buzz-phrase “fail fast” is referring to this type of system. Wouldn’t you rather discover that you are building the wrong thing days or weeks into the effort, rather than months or even years? Scrum was created to ensure that the most valuable thing that the team can feasibly produce is being built at any given time. In order to achieve this outcome, the daily standup, Sprint Planning, Sprint Review, and Sprint Retrospective events are all required to open and close those feedback loops.

Kanban

Where Scrum focuses on frequent feedback loops to maximize value, Kanban is all about efficiency. Since the team doesn’t know where the work is coming from or when, Kanban focuses on the delivery engine itself. There is no Sprint boundary in Kanban, because it is very difficult to anticipate when the work will come, and at what volume. For this reason, the constraint to support sustainable pace lies not with a calendar boundary, but with a work in progress limiter.

Kanban was created by Taiichi Ohno at Toyota in the early 1940s. This system was originally designed for the manufacturing sector in response to the excessive waste and part inventory, as well as lack of product customizability generated in factories that utilized the continuous manufacturing model of the never-ending assembly line. In the factory, Kanban was used to determine when a part needed to be picked up by a different assembly line by hanging a “Kan” (sign) onto a “Ban” (board). The next workstation would pick up the Kan, and use that card as permission to begin work on the part described on the card. This decreased manufacturing inventory waste, as there were fewer unused parts that would be taking up space, due to only manufacturing what was needed for the customer order. This also enabled greater customization of customer orders by limiting the buffer time it would take to transition the lines to produce different product. A process was used called Kaizen (translating literally to change-good). During a Kaizen session, workers and engineers would inspect the delivery process and make changes to improve efficiency, such as relocating assembly lines next to each other, eliminating processes that added waste, and implementing processes that added quality.

This framework was brought into the realm of software development in the early 2000s, and it works wonderfully for teams that do not have a consistent work intake. Much like the Toyota factories, teams will take “Kan” usually in the form of tickets, requests, or work items, and use those as permission to work. These tickets will be placed on a task board that visualizes the workflow of the team. With a team adding new network appliances to a data center, the flow might look like this: requisition > rack and stack > install firmware > push device config through Nautobot > execute performance testing > hand off to Operations team. As with factory assembly lines, there is only so much a team can work on at the same time on any one of these states before the system breaks. This is enforced by work-in-progress limiters per column on the board. These work-in-progress limiters act to visualize bottlenecks in the process, and to find the team’s predictable pace. If tickets are piling up in one of the states, let’s say the “install firmware” state, the team might have a Kaizen session to figure out if there is a way to make this process more efficient through automation, or executing Compliance processes quicker. The team can then raise and lower work-in-progress limiters to accommodate staffing, dependencies, and task time as needed, until the system reaches equilibrium.

A Word About Constraints

When picking an Agile framework to implement, it is tempting to select only the practices that look attractive or exciting and exclude practices that may be difficult to execute. Usually, practices that teams sometimes try to exclude are the constraints: the Sprint boundary if using Scrum and the work-in-progress limiters if using Kanban. People often do not want to implement these constraints because they are uncomfortable when teams bump up against them. They are also the most valuable of the processes in these frameworks. These constraints give the team a very important capability: the ability to say “no” or “not yet” to stakeholder randomization.

In Scrum, a team with a predictable velocity measured by how many story points the team completes within the Sprint boundary, is able to communicate to stakeholders how long a project or a set of capabilities will take with a good degree of accuracy. When a stakeholder comes to the team and requests something to go faster, or contain more scope, the team can push back and state that they can definitely take something in during the next Sprint, but something else must come off the table. In this way, the team can maintain sustainable pace without falling into a “hero culture” of getting it done at all costs.

In Kanban, a team with a consistent Lead Time and Cycle Time can state that tickets will be completed at a certain rate, and that the input queue is fluid, and ordered such that the highest priority tickets come first. This pushes the negotiation to the different stakeholders and requestors to figure out amongst themselves what the priority should be, and the team can keep producing at their pace. Other teams simply follow the first-in-first-out model. Either way, the team works at a sustainable pace, and if the needs of the organization exceed the capabilities of the team, then the conversation is systems oriented (how and where do more people need to be staffed, or what systems need to change?) thereby raising the capability of the team and still keeping the sustainable pace, rather than asking the team to work nights and weekends, and other silliness like that.

By choosing to ignore the constraints prescribed in Scrum and Kanban, you are choosing to let stakeholders dictate your pace and compromise your work-life balance, as there is no data to refer to when pushing back on unreasonable requests. Embrace the constraint, and it will save you.

SAFe (Scaled Agile Framework)

Sometimes companies, particularly large ones, will have initiatives that span Sprints, quarters, or even years, and involve many teams that must collaborate together. It is for these efforts that SAFe was created. There are many other frameworks that fill this need, such as Scrum at Scale, LeSS, DAD, etc., but we will focus on SAFe here, as this is the framework that most large-scale organizations tend to gravitate towards.

SAFe is a bit controversial in the Agile community, as the infographic here can appear a bit like Waterfall at first glance. This is largely due to the complexity of the fully executed system and the fact that SAFe thinks beyond the short term. At its most basic, SAFe is Scrum extrapolated up one or more levels. Where a Scrum team has a Sprint Planning, Daily Standups, a Sprint Review, and a Sprint Retrospective over the course of a Sprint, SAFe has a PI (Product Increment) Planning, Scrum of Scrums, a System Demo, and a PI Retrospective over the course of a release. The Product Increments are the pieces of value that are delivered within an iteration larger than a Sprint (usually a quarter) by a collection of teams. These teams together are called a “Release Train,” and product releasing is iterative, much like a train schedule. A good way to remember this, is if a team does not have something ready to be released, or they needed to pivot based on the business need, they can simply wait for the next train to come along to deploy. This is in sharp contrast to Waterfall, where everything defined in the initial project plan must be delivered at the end of the project.

One of the mistakes that practitioners often make is to use all of the practices in Full SAFe for all projects that are in flight in an organization. This is where I diverge from my previous statements about ignoring parts of the framework; in this case, SAFe is so extensive that it is best to use it as a toolbox to draw from, based on the type of project that you are working on. In fact, SAFe itself encourages this. The system is modular for different types of projects:

  • Essential SAFe: This suite of processes is designed for smaller projects, where a few teams have dependencies on one another and are working to deliver a connected set of value in a product increment.
  • Large Solution SAFe: This variant has processes to accommodate very large projects with many teams that are all working on different interrelated aspects of feature delivery.
  • Portfolio SAFe: This type of SAFe contains tools for initiatives that require portfolio oversight and need to map to various funding sources to provide traceability for investments.
  • Full SAFe: This variant contains all of the processes that SAFe has to offer in one framework. Full SAFe is used for company-spanning initiatives that involve multiple departments and many different teams, and that need to trace back to company goals and core capabilities. This variant is not used very often, as these types of initiatives are relatively rare.

The biggest thing to remember when implementing SAFe, is to critically look at your organization, or Release Train, implement the processes that make the most sense for the type of endeavor you are facilitating, and avoid over-processing. In fact, if your project only involves one team working on one backlog, then it probably does not even make sense to use SAFe at all.

Conclusion

When selecting an Agile methodology, it is easy to get lost in the weeds. We are hardwired to look for the quick solution that will fix our problems, so our brains gravitate towards the processes in the frameworks above. When selecting and implementing a framework though, it is critical to remember the why behind it. When we know how and why the various events, artifacts, and roles in an Agile framework work the way they do to add value, increase efficiency, and maintain sustainable pace, the implementation of the framework has a much better chance at being successful. When the implementation is successful, it gives the team and organization the space to live the values of Agile, Scrum, and Kanban. Practicing both the processes and the values, with a firm understanding of why they exist, will create an organization that is unstoppable.

-Patrick

Read the whole story
JayM
19 hours ago
reply
Atlanta, GA
Share this story
Delete
Next Page of Stories