Playing the Software Development Game

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 “pro

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.

The problem of demand for IT services and project resources exceeding available supply is something every organization faces.  I was asked again recently about how Agile helps with demand management. Agile addresses the problem in several ways. First, an Agile team's highest priority is to satisfy the customer through early and continuous delivery of valuable software.  Unbridled demand almost always will exceed resource capacity, but increasing flow of finished work from the development organization definitely results in higher levels of satisfaction from those who produce the demand. Further, delivering working software frequently, from a couple weeks to a couple months, with a preference to the shorter timescale, means a team satisfies demand on a more regular basis and on a timeframe that corresponds to the customer's ability to absorb and implement new features and enhancements. Finally, Agile processes promote sustainable development.  Sponsors, developers, and us

I've had the opportunity to perform assessments of several product and technology organizations looking for help with their Agile transformation efforts. When I do an assessment I like to use something like the Dreyfus Model , with these 5 distinct stages: Novice, Advanced Beginner, Competent, Proficient, Expert.  Here's how that plays out in a couple areas: Team/People/Roles Expert - high levels of trust, communication and collaboration with a focus on meeting commitments. Whole is greater than the sum of the parts. Performing stage in Tuckman's model Proficient - all members engage in planning and estimation activities. Norming stage in Tuckman Competent - one or two members dominate planning, estimating and retrospective activities. Between Storming and Norming. Advanced Beginner - team has not worked together through more than one cycle. Toxic patterns may be evident. Forming to Storming Novice - Low levels of trust, communication and collaboration. Forming sta

I'm old enough and have worked enough places, including large corporations, a government agency, and several smaller less-formal tech companies, to have experienced a wide range of approaches to performance evaluation. I've liked some of the tools I've experienced, but I can't recall a supervisor who did the performance planning and review/evaluation process in a constructive way.  And unfortunately my experience is not unique. I've used a process and tool with some success at a few different companies.  I think I got the basic ideas from the book First, Break All The Rules .  The authors, Buckingham and Coffman, talk about 4 keys of great managers: Select the person (select for talent, not simply experience, intelligence or determination) Set expectations (define the right outcomes, not the right steps) Motivate the person (focus on strengths not on weakness) Develop the person (find the right fit, not simply the next rung on the ladder)  They also ide

I've worked in several organizations that had a reporting team in the IT organization.  Typically report developers work with the DBA team to respond to requests from business units for custom report development and enhancements to existing reports.  They have some SQL skills, skills using the reporting tools, and some business knowledge.  Like so most others in the IT org, they have too much to do and not much process or structure around how requests to them are prioritized, how their work is delivered, and success criteria. Frustration on the part of business users often leads to everyone having his or her own private data store in the form of Excel spreadsheets or Access databases. In one company, the COO had 4 years of month-end data in one spreadsheet file on her local hard drive.  In another large, multi-billion dollar company the CFO presented monthly financial reports to his leadership team consisting of bar and line graphs on powerpoint slides that he manipulated to re

Gene Kim and others at IT Revolution have described Three Ways: The Principles Underpinning DevOps . The Third Way is about creating a culture that fosters two things: Continual experimentation, taking risks and learning from failure; and, Understanding that repetition and practice are the prerequisites to mastery. My good friend Doug Barlow recently described to a meeting of Agile Executives the work that his team has been doing at Ancestry.com.  Doug's team was acting on direction from his CTO to get the company's technology onto open source, cloud-based technologies from the proprietary platform in their hosted data center. Doug was able to build a team of volunteers from both the development and operations sides of the IT organization.  He's the kind of leader who encourages experimentation and risk taking, as well as mastery of technical knowledge and skills to allow the team to recover quickly when they've gone too far into the danger zone. The team

Somewhere I read that 20 years from now the typical office worker's daily tasks will consist of what today really smart people are doing in their spare time (I really wish I could remember where I read that). I decided to test that out by evaluating the work being done in companies with which I'm familiar.  The majority of work in terms of hours spent seems to be done by these types of employees: Customer support representatives (CSRs) Finance/accounting clerks and analysts Sales people chasing leads The tools they use consist of: Email Spreadsheets Phone So, what were the smart people doing 20 years ago that corresponds to what these people are doing today, in 2016?  I can't say I was one of those smart people, but I was around in 1996 and I was beginning to work more and more with technology. According to this article , in 1996, the internet had 10 million active users (although this article says it was 20 million) and about 35 million people used e

VersionOne publishes an annual State of Agile survey (see the 2016 9th annual report here ).  Each survey includes impediments to Agile success in an organization.  Among the leading causes of failure in Agile transformation, and barriers to future success, are: Company philosophy or culture at odds with core Agile values A broader organizational or communications problem Lack of management support Lack of support for cultural transition General organizational resistance to change Management concerns about lack of upfront planning Concerns about a loss of management control Concerns about the ability to scale agile Perceived time and cost to make the transition In my experience, leaders above the director level throughout an organization think of Agile as applicable to software development teams and typically invest little of their time and energy to understand it and how their understanding and involvement influence the success or failure of Agile transformation efforts.

I've worked at a couple companies that have eliminated all software Test/QA roles.  The CTOs at both provided the rationale that they place full responsibility for quality on software developers and that the presence of testers or QA engineers allowed software engineers to shirk that responsibility. I've not seen an implementation of teams without testing that provides business value equal to teams with testing.  In my admittedly limited personal experience, teams without testing impose on themselves and their stakeholders/users a high cost of quality.  And this is understandable and to be expected. When you consider the range of factors that affect product quality and success from the stakeholder and end user perspective, many of them fall outside the domain of control of the software developer in an Agile framework. Considering the broad and varied range of quality concerns, it's seems obvious that much that can and should be tested fall outside the scope of t

Here’s the Jeff Sutherland and Scott Downey document on which we based our Backcountry.com version of Scrum KPIs (I worked on this with the PMO at Backcountry, including Michael Burleson and other project managers and scrum masters): http://jeffsutherland.com/ScrumMetricsHICSS2013BWSubmissionFinal.pdf See also the Software Development Performance Index . Overview A set of Key Performance Indicators (KPIs) provides Product Teams with a standardized set of metrics to help gauge their success at delivering value and meeting commitments each Sprint. What are the metrics? Focus Factor - Ratio of Story Points accepted to the team's work capacity in the Sprint Adopted Work % -  Ratio of work brought into the sprint after the original planning sessions to the work committed to in the original planning session. Found Work % - Ratio of incremental story points based on learning once in the sprint vs the original commitment for the Sprint. Commitment Accuracy %

I came across Bret Pettis' Cult of Done Manifesto several years ago and fell in love with it. You need to check it out at that link and ponder the graphic he includes, but I'll give you his twelve points here: The Cult of Done Manifesto There are three states of being. Not knowing, action and completion. Accept that everything is a draft. It helps to get it done. There is no editing stage. Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it. Banish procrastination. If you wait more than a week to get an idea done, abandon it. The point of being done is not to finish but to get other things done. Once you're done you can throw it away. Laugh at perfection. It's boring and keeps you from being done. People without dirty hands are wrong. Doing something makes you right. Failure counts as done. So do mistakes. Destruction is a variant

I had the opportunity while Director of IT at Green River Capital to get the organization in compliance with SSAE-16 (SAS 70 at the time), part of the Service Organization Control (SOC) reporting framework.  We were using Scrum on our software development team, and I was eager to do all the things required to demonstrate operational controls while not imposing burdens or requirements on the team that would be impediments to good Scrum practices and principles. The SOC-1 audit was required in order for the company to be a vendor to large mortgage lenders and servicers including Bank of America, Chase, Fannie Mae and Freddie Mac. I didn't know about it at the time, but Gene Kim has worked with the Institute for Internal Auditors to develop the GAIT principles and methodology .  Here are the 4 principles: The four principles that form the basis for the methodology are consistent with the methodology described in the Public Company Accounting Oversight Board's Auditing Stan