Posts

Showing posts with the label Project Management

Build Test Adapt Check - When will I know if it works

Image
Starting with a good foundation puts us in a position to step into a build/test/check/adapt iteration loop that drives an expanding and improving product or experience. The key is to figure out how to measure success from the customer, organization, regulatory or privacy, and other non-functional requirements perspectives. We want to optimize the Build - Test - Adapt - Check  cycle in order to make good changes with a short cycle time. Hopefully, I'll add the content of this talk in the future.  Until then you have the diagram and the video. Video Here is the video where I go over the diagram. Revision History Created 2024 11

Programmers' Credo: "We do these things not because they are easy...

Image
Yet another tool in our understimation arsenal. We do these things not because they are easy, but because we  thought  they were going to be easy. This applies to more than programming.  I'm looking at you, my most recent repair project. Credit goes to Jeff Atwood  around 2016 Revision History 2023 11

A bank CIO once told us every project was on time or coming in early

Image
I worked for a vendor at a bank in the early 2000s. We raised the issue of how many programs and projects were off-course in an already-planned meeting with a CIO. The CIO said we were off base and that  We have 320 software projects in flight - 315 on time - 5 will be early The reality was that everything went to production in Q4. The next year's Q1 was filled with production fixes. I'm pretty sure the real story was Real-time information radiators have given a different impression Question Did the executive know what was happening but was defending their teams? Was the true health hidden from the executive? Did the company not have accurate metrics? Does anyone believe that all their software projects were on time or early? Maybe they just keep adjusting dates until they are accurate. It was not a feature driven agile shop that delivered incrementally Were bonuses the primary drivers for this viewpoint? Revision History Created 2023 06 

Management by Impossible Objective

Image
Management by Impossible Objective  is a style based on the idea that people will produce more in less time if they are given goals that are difficult to achieve.  It often morphs into goals that are impossible to achieve based on the notion that the only way to max out productivity is to pick a target that is above what is achievable causing people to work as fast as possible. There is some truth to the argument that people can procrastinate until they have well-defined targets. The idea breaks down when people realize or come to believe that the targets are unreasonable or made without an understanding of the details that went into the estimate. Agile takes a different approach that delivers continuous incremental value. Work is done until the backlog is complete or the ROI is less than the cost being invested. Video Images Used Speaker notes at some future date References https://hbr.org/2017/01/managing-a-team-thats-...

We fought Conaway's law and the law won

Image
Conway's law says systems, software, and wetware, end up shaped like the organizational structure that designed them or that they are designed for.   Organizations understand this at some level. Much of the corporate re-organization efforts are fed by people trying to change the corporate structure to push closer together the people creating a new paradigm or system.  The other main approach is to live with the partitioning that aligns with the organizational structure allowing any global redundancy or other inefficiencies. Video Images used in Video Conway's law states that software systems will be designed and built with the same alignment and partitioning as the organization that built created the software.  Teams that are closer together organizationally will build software that works better together. Teams that are farther apart will build software more loosely coupled or more error-prone.   We see the same behavior for non-software ecosystems.  C...

Every Team is Successful and You still Failed

Image
Decoupling tasks makes it possible for teams to operate in a more agile fashion. It can also create a situation where a project fails even though every team declared success. This often happens because no one is minding the gaps between teams or managing the ordering for dependencies. I'm not suggesting you go to a waterfall style federal PMO.  Instead, create a process for tracking dependencies and a regular cadence for discussing them and working through the issues. Video The video is only 10:00 minutes long so it doesn't solve all problems. It is really just intended as a way of starting a discussion[   Slides These are the slides used in the presentation. Someday I will add speaker's notes :-( Slides not Presented

A portable Program Increment (PI) planning wall

Image
Program Increment Planning is a powerful piece of the SAFE framework that provides a structured way of managing cross team work in time blocks larger than a development sprint.  It provides Program level view into something that is otherwise a set of independent of team streams. My current team meets for 1-1/2 days on a quarterly basis to align the next quarter's deliverables.  We bring in our 5 development teams, the product owners, the business line product owners and our cross functional support teams, DBA, CM, OPS, etc.  This meeting gives a one wall view of our coordinated deliverables and exposes our cross team dependencies and their timeframes. Our PI planning wall is normally 8 feet tall and probably 8 feet wide.  We have struggled with how to maintain the wall after the PI planning so that we can track how well the plan reflected the actual work we do/did.  I recently visited with AmTote International. Their Agile Program Director gave us a qu...

Black Swan IT Projects: The Loan Servicing mainframe replacement

This blog discuss a little the "the Mainframe Servicing System Migration", a project that should considered a  Black Swan A Black Swan Event    The  black swan theory  or  theory of black swan events  is a  metaphor  that describes an event that comes as a surprise, has a major effect, and is often inappropriately rationalized after the fact with the benefit of  hindsight . The term is based on an ancient saying which presumed black swans did not exist, but the saying was rewritten after  black swans  were discovered in the wild.  The Fannie Mae loan processing servicing system replacement was Initially budgeted for  18 months and $75M.  Eventually cost about  72 months and > $800M. The project turned out to be a black swan that could have bankrupted other less stable companies. In the Mid 2000s Fannie Mae closed out either Q3 or Q4 in that year with a recorded profit of $1B. This was ...