Playing the Software Development Game

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

Recently I've been engaged with a couple companies in discussions of whether to use Scrum or Kanban for their work.  I've published a deck on slideshare  that I've used in detailed discussions of the subject.  I'll capture a few of the points from that deck here. Scrum of course is an Agile practice and is based on the Agile Manifesto and accompanying principles .  Kanban is a Lean practice that should be understood in the context of the Toyota Production System (TPS) I like this diagram illustrating the shared precepts of the perishable nature of knowledge work and continuous improvement.  Outside that shared space are the driving forces behind Lean: eliminating waste and emphasizing throughput; and in the Agile domain: releasing work early and often, and the need for trust and collaboration. To elaborate further, here's a summary list of similarities I see between Scrum and Kanban: Pull scheduling WIP limits Transparency drives process improvement

The New York Times recently published this article that describes efforts at Google to identify what makes teams great.  I think the findings are not surprising and align with Scrum values . According to the NYT, Google researchers noticed two behaviors that all good teams shared: Equality in Distribution of Conversational Turn-taking.  On the good teams, members spoke in roughly the same proportion. On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment.  But in each case, by the end of the day, everyone had spoken roughly the same amount.  "As long as everyone got a chance to talk, the team did well . . . But if only one person or a small group spoke all the time, the collective intelligence declined." High Average Social Sensitivity.  On the good teams, members were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues.  People seemed to know

I was skiing recently with Brian Rabon , President of The Braintrust Consulting Group .  Brian offers leadership training and coaching through the Center for Agile Leadership (CAL), and through that experience and his own participation in a large number of executive leadership training offerings he's had the opportunity to get to know a lot of executives at organizations of all shapes and sizes. Brian and I were skiing at the gigantic Park City - Canyons ski area.  While riding the Quicksilver Gondola that links Canyons to Park City Mountain Resort we discussed our observations of impediments to success.  Here's a summary: Lack of trust.  When leaders don't trust others in the organization they put inordinate demands on them and require hours of non-productive efforts in the form of reports and meetings Inability to translate strategy to tactics.  Leaders spend their time and energy thinking of strategic goals for the company. Failure to create a clear connection bet

Over the years I've worked on a way to represent a typical PO calendar.  Having a cadence to work helps a PO organize herself to be able to accomplish more of the wide range of activities required of her. The PO's job requires her to think and act at higher strategic levels as well as in day-to-day tactical mode.  It requires that she get out of the building to meet with and observe end users of her product, and also to get around inside the building to meet with internal stakeholders to communicate with them.  And she has to engage with the team regularly throughout the Sprint to accept work, resolve issues and concerns, answer questions, give praise and encouragement, and get vital feedback from those with hands on keys developing solutions. Here's my latest attempt (or check it out here as a Google sheet): PO Calendar for 1+ Sprints Here's how to read it: The Phase/Level column puts activities into one of these phases or levels: Discovery Phase Backlo

The subject of this post has given me difficulty over the years for a couple reasons:  First and foremost, I have the urge to tell the team what needs to be done, and an accompanying fear that if I don't have a say in how they do it they'll get it wrong; and second, I didn't really understand how a team was to organize itself. One thing that has helped me lately with regard to the second point is acknowledging and getting more comfortable with the fact that software development is a creative activity.  The quality of the product is highly dependent on many factors, including the knowledge, skills, and creative capacity of the people producing it.  I've managed teams of translators and teams of UX/UI designers and understand how hard it is to drive their work through formulas and rigid process structures. I had always thought of software development as more like electrical or mechanical engineering.  If I could give the developers a spec, even in the form of a well-w