Product v Project Focus in Software Development

By -

Product v Project Focus in Software Development

Many IT organizations use a traditional project approach to software development. Agile success is dependent on forming product teams that have these characteristics:
  • A defined focus area (application, domain, system, etc.)
  • Persistent over time
  • Cross-functional skillsets, giving it the ability to deliver a fully baked solution in each iteration
  •  “Concept to cash” responsibility—taking work from early discovery and design steps through delivery and into production deployment and operational support
It’s important to understand the difference between product focus and project focus. A product team can still deliver value in a project context, but the way the team is organized and delivers is very different. Here are some contrasting characteristics:

Product
Project
People
Team is primary means of creating value. They stay together over a long period of time and over multiple “projects” as a self-organizing unit.
Treated as specialists in functional silos; focus is on 100% utilization (watching the runner, not the baton). Spread thin across multiple simultaneous projects, each competing for his or her attention. Death marches and heroes are common.
Customer
Integral part of team; key to defining value and providing feedback on deliverables. Partners with team to define roadmap in terms of business value.
A request submitter. Incentivized to create large project requests because they get one shot at success, then relegated to back of line. Confused about who they can get info/updates from. 
Demand Management
One prioritized backlog per product.
Repository of an unlimited number of requests of all shapes and sizes. Plan-driven resource allocation.
Delivery
Iterative and incremental with focus on highest value soonest. Opportunity to change priority regularly.
Unpredictable and unreliable. Project at constant risk of being put on hold or deferred. 
Quality
Integral to every work item; owned by the entire team. Benefits of collective code ownership and continuous refactoring to reduce tech debt.
Most frequently sacrificed characteristic in a plan-driven, deadline-oriented project. Highly variable from project to project because a continuous improvement process is lacking.
Intangibles
Higher level of commitment from the team due to higher levels of ownership and accountability. 
Lower commitment levels due to a sense that “this project will get put on hold before its finished;” and “we were given a set of mandatory requirements that we just have to get through.”
Continuous Improvement
Teams inspect and adapt each sprint cycle. They evaluate all aspects of the product, including feature quality, defect level, tech debt level, and architectural integrity.
Project team disbands and members move on to next project. Long cycles and unique work mean no opportunity to regularly inspect and adapt. Ad-hoc teams mean individual performance standard and improvement path. Hero culture.
Passion Level
·        Missionary
·        Problem solver
·        Innovator
·        Mercenary
·        Do the minimum amount required to get sign off
·        Hack

Plan-driven traditional project approaches apply industrial process efficiency principles and practices that are poorly aligned with the realities of software development. Agile product teams are more aligned with principles and practices that work best for the type of creative, problem-solving work that is software development.

The choice of product teams over a traditional project approach to software development creates a foundation for achieving organizational goals of high quality software delivered on a regular, predictable cadence, and highly engaged and focused people.

Here's a great presentation by David Hawk at Keep Austin Agile 2017:

Comments

Post a Comment

Popular posts from this blog

Severity, Priority, Impact and Likelihood - Managing Defects and Risks

By -
Defects and Risks are often dealt with in a subjective, emotional way.  That's unfortunate, because among all the things a software development team deals with, those are two that can be handled in a more constructive and empirical way. First, a couple definitions. Defect Severity: the degree of impact a defect has on system operation. A defect is something observed, so impact can be empirically quantified. Risk Severity: the degree to which a hypothetical event, should it occur, would impact system operation. A risk event is something that has not occurred, so impact must be estimated or extrapolated. The common element in both Risk Severity Assessment and Defect Severity is Impact on Revenue.  The FMEA framework that AKF recommends uses 1 = Low, 3 = Med, and 9 = High, to represent the exponential effect of a high impact risk or defect Impact on Revenue No payments being collected and/or payment data security compromised (Critical) Payment collection being de
Read more

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

By -
Image
Brian Rabon introduced me to the Entrepreneurial Operating System (EOS) as the framework he uses to manage his company, The Braintrust Consulting Group (TBCG). EOS is the missing element in organizations that are having some success with Agile at the team level, but not succeeding with change at higher levels or outside software development. As Charlie Rudd points out in his post The Third Wave of Agile , there is broad consensus on the value of Agile practices at the team level, but all types and sizes of businesses are struggling to scale Agile and to increase agility across their organization.  I think EOS addresses those challenges. EOS is comprised of the EOS Model : Having a model like this in place allows teams to function optimally as self-organized units that share the vision and goals of the organization.  Teams are able to align themselves with the organization's objectives, and can see how their outcomes affect the organization's performance. The EO
Read more

Chatbot Code of Ethics

By -
A  NYTimes article  describes efforts by a consortium of the largest technology companies to create ethical standards for AI. A related article in MIT Technology Review is titled  AI Wants to Be Your Bro, Not Your Foe . Artificial Intelligence has reached a level of sophistication, and is on the brink of being so pervasive, that we can have these serious conversations. In my work developing AI-powered chatbots to assist with learning, I work within the bounds of these 7 precepts: Right View - our chatbots honor humanity, human dignity, and the human quest for knowledge, understanding and technological innovation Right Intention - our chatbots promote human progress in the areas of intellectual pursuits and personal ethical development Right Speech - our chatbots use encouraging, prudent, and situationally appropriate language Right Action - our chatbots perform with integrity toward the aforementioned right view and intention Right Live
Read more