You adopt practice to “make the team go”. However, every practice you adopt has a cost. The time you spend “making the practice go” is somewhat then a cost of making the team go. I like to talk about the cost of your practices as “Feed the Beast!” But what you really want to make your team go is to “Ride the Beast!” where the practices we have adopted start to carry the team faster than they could go without them.Continue Reading
Posts Tagged with delivery
Speed and Friction
In a recent news story, Paul Walker, famously of the “Fast and Furious” movie series died in a car crash when he and a friend wrapped a Porsche GT3 around a tree. According to reports, they were going too fast for the condition of the car when they lost traction and spun off the roadway. The Porsche GT3 is a highly capable sports car, capable of speeds exceeding 180 mph. It is a descendant of the famous Porsche 911 which shares a rear engine, rear drive configuration with the lowly Volkswagen Beetle. Continue Reading
Top 5 Reasons to use Sequence rather than Priority
I influence software delivery. Software delivery is abstract and complex. It is abstract because most people don’t really understand what happens behind the bit curtain. It is complex because it requires the translation across many layers of abstraction and back and sometimes the value is lost in translation.
I say that I influence it, because my job is to increase the probability of success. To make projects more effective. I do not manage the team. I do not decide the deliverables. I do not even run the process. I do not write the code, very often.
What I do, mostly, is give delivery teams ideas and concepts that can help them increase their probability of success. What I do, secondly, is to convince their customers that those ideas are important, and that their (the customer’s) role is as or more important in the success of the delivery than the technicians who are writing the code.
What is my number one idea? Sequence! Continue Reading
Early Delivery Part 2 (from my old blog)
Early delivery has been considered the first commandment of agile. In the principles behind the Afile Manifesto, the first paragraphs says:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
2) For a more enterprise software application, used by employees of a company, the cost of deploying and retraining staff on new software features, and the criticality of correctness. The business process change management around delivery of new software features may drive a very different roll-out cycle.
3) A software vendor, selling software to business units within an enterprise, or small businesses, may have yet another model for making decisions about deployment. They may be driven by demands from new customers, and prospects, as well as a backlog of requests from existing customers.
4) Software that is to be “embedded” in a physical device may have a completely different decisions cycle, and a much more rigid schedule. The delivery of the rest of the device into which the software is to be embedded, and the revenue derived from the sales of the devices, completely determine the schedule. In this model, partial delivery has little or minimal value.
5) Software that is deployed in industries that are heavily regulated (blood bank) or that have critical quality requirements (military/aerospace) may have much more rigid schedules that are driven by decisions made well before the development starts. In this model, the ultra-high cost of quality assuranceand regulatory certification reduces the value of partial delivery to near zero. It is easy to see why the value of agile principles is readily apparent to some, and a complete mystery to others. It is the decision model that works in between need and deployment that determines the value of early or frequent delivery. From a whole project perspective, this is clear. But let’s look from a intraproject perspective.