Playing the Software Development Game

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

Reading Sanjiv Augustine 's excellent Managing Agile Projects recently I was reminded of some Lean principles that portfolio and program managers could apply at their level to manage the flow of work to product teams: Small Batch Size . Agile teams use iterative development to avoid the issues caused by large batch size—lack of early feedback, large inventory, and associated potential waste of time and resources.  Small releases and iterative development provide two levels at which batch size can be controlled. At the portfolio level you can work with customers to define, create and release system functionality in small batches (feature sets, project phases, etc.). Steady Rate of Arrival and Delivery . All backlogs are queues.  There are queues at the portfolio level, the product backlog, and the sprint backlog.  Large queues are an indication of inefficiency.  Gathering inputs in the form of requirements and requests at a rate that exceeds the delivery rate creates long qu

I was at a client recently where a scrum team member asked me about re-pointing a story that the team had estimated during a backlog refinement meeting.  A couple sprints had passed since that meeting, and when the story came to the top of the backlog to be played in the next Sprint, he thought the point value it had been given was no longer accurate so the team ought to have another opportunity to estimate the story. For many good reasons the team had followed a practice of not re-pointing stories.  The rationale for that practice included: The purpose of story point estimation is to reach a shared understanding of the story and provide an indication to the Product Owner of the level of effort required to deliver it, relative to other stories on the backlog A practice of re-pointing stories can encourage the type of "analysis paralysis" that a team experiences when it tries to provide precise hour estimates for a story or use case.