Four Factors to Address When Implementing Capability Teams

There are those who believe that implementing a capability team is as easy as identifying a group of people, putting them together, and then doing a few team building exercises. Instant team! In the simplest terms possible – they are wrong.  There are four complicating factors that have to be addressed.

 

SPaMCAST 420 – John Hunter, Building Organizational Capability

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 420 features our interview with John Hunter.  John is a SPaMCAST alumni; John first appeared on SPaMCAST 226 to talk about why management matters.  In this podcast John returns to discuss building capability in the organization and  understanding the impact of  variation.  We also talked Deming and why people tack the word improvement on almost anything!   

John’s Bio

John Hunter has served as an information technology program manager for the Office of Secretary of Defense Quality Management Office, the White House Military Office and the American Society for Engineering Education.

In 2013, he published his first book – Management Matters: Building Enterprise Capability.

John created and operates one of the first, and still one of the most popular, management resources on the internet.  He continues to aid managers in their efforts to improve their organizations with an emphasis on software development and leveraging the internet.  His blog is widely recognized as a valuable resource for leaders and managers with a focus on improving the practice of management in organizations.

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we tackle the sections titled Accountability, Individual Contributor, and The Talk.  We are getting close to the end of the novel portion of the book but over the next few weeks, we have a number of ideas to extract from the book before we review the model.

 

SPaMCAST 416 – Kirk Botula, Agility and Capability

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast features our interview with Kirk Botula on capability.  Kirk makes the argument that capability is crucial for organizational health and agility.

Kirk Botula is the CEO of the CMMI® Institute, the home of the globally-adopted capability improvement framework that guides organizations in high-performance operations. Botula is a global growth company executive whose career has been focused on advancing the common good through the commercialization of technology. Prior to CMMI Institute, Botula served as President of Confluence, a global financial technology firm with operations in North America, EMEA and Asia.

During his tenure, Confluence became the leading provider in its space achieving market share exceeding 70% in North America and 20% globally, while delivering the industry leading NPS of 40. Botula also served at BNY Mellon, Compunetix, and as a strategist to a variety of nonprofit and for-profit organizations. He has a BFA and MSIA from Carnegie Mellon University and lives in Pittsburgh with his wife and three daughters.

Reach out to Kirk at info@cmmiinstitute.com

 

Starting An Agile Effort: People

A good team will not go to pieces!

One of the most iconic television shows of the 1980s (83 – 87) was the A-Team. In the A-Team, the four team members combined their talents to right wrongs and conquer evil. In a precursor to Agile, the team was cross functional and in the context of the larger world, self-organizing. While the A-Team reflects Hollywood’s perception of a team, the lesson shouldn’t be lost that for most software development or maintenance efforts teams are necessary to get things done. If teams are a necessity, then it is important to understand the attributes of an effective team.  For any specific effort, the best team (or teams) is a function of team dynamics, capabilities and the right number of bodies.

 

Five Problems That Impact Testing Effectiveness and Efficiency: #4 Capability

In order to participate you have to be capable.

Testing effectiveness and efficiency will suffer if the organization or team does not have the capability to test well. Testing with the proper level of capability is akin to trying to drive from Cleveland, Ohio to Washington, DC in a car with four flat tires.  It could be done, but at what cost?  Capabilities include the number of testers, clarity of responsibilities, expertise, tools and environments.  Problems in any of these categories will affect the effectiveness and efficiency of testing.

• The number of testers – There is no fixed ratio of testers to developers however too few testers will cause corners to be cut. The development methods used, amount of test automation available, application criticality and the ability of others in the organization to augment the ranks of testers will all impact the required staffing level. The business needs and test goals and strategy will also influence staffing levels for testers.
• Clarity of responsibilities – The responsibilities for testing in teams can be easily delineated if the team is cross functional with a mix of developers and testers supporting a common delivery goal. Techniques, such as stand-up meetings, are useful for ensuring everyone knows the work they are responsible for completing. As the number of teams increase, ensuring testing responsibilities are understood become more problematic.  Techniques, such as SAFe’s release planning and the role of a release train engineer, can be leveraged as tools to coordinate responsibilities.
• Expertise – Just drafting anyone to do testing is a recipe for using your clients to find your defects. The core of your testing capabilities needs to be comprised of experienced (both in testing and with the application being tested) and certified testers. The core testers should lead testing efforts, but also act as consultants to support others who also are acting as testers (think cross-functional).
• Tools – Development frameworks like Agile work best when testing is performed early and often. Making testing a ubiquitous part of the development process requires test automation.  Automation is needed not only for executing tests, but for generating test data, generating code builds, and capturing defects. Good automation will lessen the testing effort burden and increase the effectiveness of testing.
• Environments – A test environment is the combination of hardware, software and data required to run software tests. Test environments should closely emulate the environment that the software will run in when it is finally installed in production.  Problems in the test environment will generally mask problems that will not be recognized until production.  The expense to implement and maintain test environments often cause organizations to cut corners on the number or makeup of test environments.

A team’s or organization’s testing capabilities are critical factors in the equation of whether testing will be effective and efficient. Capabilities encompass a broad range of factors from people to computer environments.  Being good at one might compensate a bit for weaknesses in another, but in the long run an organization needs strength in all categories testing software

 

Agile Release Plans

A dam releasing water is a release plan in action.

I have been involved with very few projects that did not have to answer the age old questions: “When are you going to deliver?” and “What are you going to deliver?” In standard waterfall projects we would answer those questions with requirements documents, charters and project schedules. In an Agile project a release plan answers the same “what” and “when” questions based organizational vision, project needs and team capabilities.

Organizational vision provides the goals and frameworks that guide product decisions. Goals describe what the organization aspires to and frameworks such as architectures describe the constraints teams operate within.

Project needs, whether they are called user stories, backlog items or just plain requirements, describe the business and technical needs of the team. Agile recognizes that needs evolve based on experience and business direction therefore release plans will change and need to be iterative.

 

Project information and team capabilities are reflected in estimates and the team’s velocity or productivity (how much work the team can accomplish per sprint). The size, complexity and team’s ability will influence how fast the team will deliver if the plan is focused on scope or how much the team can deliver if focused on calendar time.

 

Agile release plans pull together vision, project needs and capabilities to answer the questions that all project face: what will be delivered, and when will it be delivered. An Agile release plan is a mechanism for providing an answer to those age old questions.