Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management

SPaMCAST 322 – Clareice and Clyneice Chaney, Contracting, Acquisition and Agile Testing

Software Process and Measurement Cast - Sun, 12/28/2014 - 23:00

SPaMCAST 322 features our interview with Clareice and Clyneice Chaney. Clareice and Clyneice provide insights and practical advice into how Agile and contracting work together.  The focus of the interview is on contracting and acquisition of Agile testing, however the concepts we discussed can be applied to contracting for any type of service using Agile techniques.

Clyneice Chaney brings over 30 years of testing, quality assurance, and process improvement experience. Clyneice holds certifications from the American Society for Quality as a Certified Quality Manager/Organizational Excellence and Project Management Institute's Professional Project Manager. She has participated as an examiner for Baldrige state quality awards for Georgia and Virginia. She is currently an instructor for an International Testing Certification organization and has presented technical papers at the Software Engineering Institute: SEPG Conference, American Society for Quality: Quality Manager's conference, Quality Assurance Institute International Testing Conference, International Conference on Software Process Improvement and Software Test and Performance Testing Conferences.

Clareice Chaney has over 30 years’ experience in Commercial and Government Contracting with an emphasis in contracting within the information technology arena.  She holds a PMP certification with the Project Management Institute and is a certified Professional Contracts Manager (CPCM) through the National Contract Management Association (NCMA). She has presented at the National Contract Management Association World Congress and provided recent collaborations on agile testing and contracting at the Quality Assurance Institute International Conferences.

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

The next Software Process and Measurement Cast will feature our essay on the Attributes Leading to Faiure with Agile. Agile projects don’t work when there isn’t open and honest communication within a team. Problems also can occur when all team members are not involved, or if the organization has not bought into the principles of Agile. Knowing what can go wrong with Agile implementations and projects is a step to making sure they do not happen!

We will also have the next Form Follows Function column from Gene Hughson and Explaining Change with Jo Ann Sweeney.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management

Re-read Saturday: Empowering Employees for Broad-Based Action, Leading Change, John P. Kotter Chapter Seven

A trail map enables hikers to choose their own path!

A trail map enables hikers to choose their own path!

Change is a fact of life.  John P. Kotter’s book, Leading Change, defines his famous eight-stage model for change. The first stage of the model is establishing a sense of urgency. A sense of urgency provides the energy and rational for any large, long-term change program. Once a sense of urgency has been established, the second stage in the eight-stage model for change is the establishment of a guiding coalition. If a sense of urgency provides energy to drive change, a guiding coalition provides the power for making change happen. A vision, built on the foundation of urgency and a guiding coalition, represents a picture of a state of being at some point in the future. Developing a vision and strategy is only a start, the vision and strategy must be clearly and consistently communicated to build the critical mass needed to make change actually happen. Once an organization wound up and primed, the people within the organization must be empowered and let loose to create change.

I view the stages the precede stage five to be a build up to the beginning of the main course. Each step is incredibly important and ignoring any of the steps will lead to problems and failure.  However, if the change you are attempting to generate is to be broad based and long lasting, you will need to empower people.  In this chapter Kotter discusses removing barriers to empowerment. Kotter singles out four categories of barriers for examination:

  1. Structural – Organizational structure defines how the lines of authority and responsibility are constructed in order to deliver the organization’s products and services. An organization’s structures are generally developed to effectively and efficiently deliver services and products based on a specific way of working. Structures are built to guide and control work AND to resist change. Managers often defend the current structure and their own base of power leading to specialization. Specialization generates silos; fragmenting the work so that to deliver a product or service, many handoffs are required.  Handoffs slow the flow of information and communication, which accentuates the need to foster stable processes over innovation. Breaking through structural barriers requires a constant sense of urgency and senior management oversight and dedication.
  2. Skills – Change often requires reskilling employees who have spent years acquiring knowledge and skills and believe they have been successful. The act of having to acquire new skills and change what has worked in the past generates fear of the future and resistance. People fear change they do not think will benefit them or at least can’t predict will be positive. A training strategy needs to couple the experience and concepts to convince those involved with the change that they will be successful. Training to reskill employees must be designed to combat resistance and to address adult learning (see Training Strategies for Transformations and Change: Synthesis).
  3. Systems – Systems of all types need to change to empower and support employees in making change. Systems include information technology applications (e.g. customer relationship systems and logistics systems) and business processes (e.g. objectives, hiring processes, promotions). Changes to the process and systems are critical to making change possible and then supporting change.
  4. Supervisors – Not all supervisors and middle managers will support the vision and strategy for change adopted by the organization. When these leaders baulk at empowering their employees, change often grinds to a halt. Kotter suggests that you should confront the recalcitrant with honest dialog. I would add that that when the dialog occurs (the earlier the better) that the power that urgency, vision and constancy of purpose be used to get holdouts on the change train. Employees with supervisors that actively resist the change will never feel safe enough to be empowered.

Empowering employees generates power and action.  They are required to transform a vision and strategy into something tangible rather than something ethereal.  Without empowered employees, change fails.


Categories: Process Management

Five Problems That Impact Testing Effectiveness and Efficiency: #5 Process

Apparently the cleaning crew flows a process

Apparently the cleaning crew flows a process

Developing or maintaining a piece of software requires a fairly complicated set of processes, including processes for collecting requirements, designing, coding, verifying and validating a solution. All of the processes need to work together well or they risk impacting the quality of the delivered product. Process problems tend to be most severe when testing and engineering processes are mismatched, organizations embrace a one-size-fits-all testing solution or ad-hoc testing processes (gag).

  • Mismatched processes – Testing is a collaborative process requiring communication between everyone involved in developing software. When development and testing processes are not synchronized, the chance of miscommunication increases.  For example, consider the communication problems that would ensue if the developers were using Agile techniques while the testers were using waterfall techniques. Agile development techniques would be focused on delivering functional code rather than omnibus requirements or design documents that are often used to drive waterfall testing. Whether Agile, waterfall, RUP or some other framework if testing and development have not found a mechanism to synchronize how they work together, defects will make it to production.
  • One-size-fits-all testing solutions – Every project has its own set of nuances and risks. The testing solution for each project needs to be tailored to meet the specific needs of the project. A one-size-fits-all solution will tend to overemphasize specific types of testing (e.g. functional testing, system testing or integration testing) when another type may need emphasis.  For example, recently I observed a large program that initially failed on delivery because integration testing was not part of the standard process the firm used.
  • Ad-hoc testing – Ad-hoc testing (just winging it) went out of style as soon as someone thought about the quality of the code being delivered, it never worked and never will. Just don’t do this.

Development is a dance of multiple inter-related processes. Regardless of whether the project uses the team uses a mixture of extreme programming, test-driven development, black-box testing or exploratory testing the processes need to work together. Synchronized and compatible development and testing processes are critical for effectively and efficiently developing. Agile techniques leveraging cross-functional teams, that include developers and testers, put teams in the best position to ensure a synchronized process.


Categories: Process Management

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

In order to participate you have to be capable.

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


Categories: Process Management

Merry Christmas, 2014

Merry Christmas 2014

Merry Christmas 2014

Eric Sevareid, a CBS news journalist from 1939 to 1977, said, “Christmas is a necessity. There has to be at least one day of the year to remind us that we’re here for something else besides ourselves.” Whether in your day job you gather requirements, write or test code, facilitate teams or lead change Christmas represents a time to reflect on the larger world, reflect and make it better for someone other than yourself. NPR’s Morning Edition on December 24 included a segment discussing research that suggests that generosity is a hardwired human attribute.  The research by Dr. Lara Aknin is an Assistant Professor of Psychology at Simon Fraser University suggests that people feel better about themselves and the world around them when they are generous to others. Christmas is a day of celebration but also a reminder that to feel good about ourselves we need to give of ourselves to others.

Regardless of whether you celebrate Christmas, take the few minutes you would spend reading this blog and reach out to a family member you have lost track of, a co-worker that might be alone on this day or to a friend you have only talked to only on Facebook and say hello. Whether, like Fred in the Dicken’s Christmas Carol, invite your Uncle Scrooge to dinner or just spend a few minutes on the phone reaching out to another fellow human.


Categories: Process Management

Five Problems That Impact Testing Effectiveness and Efficiency: #3 Organizational Management

Expectations and environment affect behavior.

Expectations and environment affect behavior.

When I was a manager of QA (testing), my manager more than once shared the expectation that testing should have found all of the defects in a piece of software before it was put into production. I actually think that expectation found its way into my annual objectives just prior to my changing jobs. Not only is it not possible to find all defects, the responsibility for defect removal must be shared by developers and testers alike. Organizational management can impact test efficiency and effectiveness in many ways, however three are fairly common.

  1. Unrealistic expectations – One of the principles of testing is that exhaustive testing is impossible.  The over-emphasis of removing all defects or perhaps slightly less dangerous – all significant defects – takes the focus away reducing risks. Testers and test managers must use testing and other techniques (reviews, for example) to focus the available time and effort they have on what is important and risky. Developing an understanding of potential impact and possibility of problems (risk) is needed to target testing resources. That is impossible when trying to find all possible problems.
  2. Undervaluing /Underfunding testing – One the indicators of how an organization values test (and testers) is funding. Funding includes people, tools and other resources. Organizations can have enough testers and but not the proper logistics to test effectively or efficiently.  Another common indication that testing is considered a commodity or not a core function is when an organization outsources testing.
  3. Failure to pursue root causes of defects – Testing shows that defects exist (another principle of testing). Testing does not create defects; said another way defects come from somewhere else. The only way to stem the tide of defects is to change how the software is developed by improving the development process (inclusive of people, process and tools) by finding the root cause of defects and then improving the process. If process improvement does not include the development process the rate of defects production will not change. Ignoring the lessons from defects found in testing dooms the organization to repeating the mistakes that led to those defects.

Organizational management can have a direct impact on the effectiveness and efficiency of testing.  The actions that are taken are very rarely because they want buggy software, but rather because they are unsure of the role, scope and goal of testing in the development and maintenance of software.  As a general rule, the role of testing whether through reviews requirements, design and code or by executing cases is to find defects. Software is complex enough that exhaustive testing is either not possible or not cost effective, therefore the goal of testing is to reduce the risk to the users of the software (and to the organization) that defects that will be delivered. The organization has the responsibility to provide the resources and tools needed to meet the goals and strategy of the testing that is needed to meet the organization’s goals.


Categories: Process Management

Five Problems That Impact Testing Effectiveness and Efficiency: #2 Involvement

 

Riding a horse requires the involvement of the horse!

Riding a horse requires the involvement of the horse!

Effective testing scenarios require a tester to work with users, product owners, business analysts, developers and others to determine whether a deliverable is what it is supposed to be, whether it meets the definition of done and standards of quality. Testing is a collaborative enterprise. Testing is less effective when the right people are not involved in testing. In order to meet the basic level of collaborative involvement for effective testing, testers need interaction with the broad stakeholder community in three broad categories of activity. They are:

  1. Developing requirements – Requirements, whether written as user stories, use cases or paragraphs of text, are a critical input into the testing process. Requirements become the basis of comparison to determine if what is being developed is what the the business wants. Business and technical stakeholders provide the input that becomes the requirements. Testing provides feedback to challenge the assumptions of the stakeholders and development teams as the requirements are formed, groomed and transformed into functional code.
  2. Defining realistic acceptance tests and criteria – A well-formed user story includes not only the story itself, but a set of acceptance criteria. Acceptance criteria provide the development team both with a deeper understanding of how to interpret the story and with a tool to understand when development is complete. Business and technical stakeholders provide the diversity of knowledge to develop relevant acceptance tests and criteria. When testing is a silo’ed task the development team will have to make assumptions that will need to be validated later in the process (later is never better than sooner when it comes to validation). Agile roles such as the product owner and techniques like the Three Amigos are tools to codify involvement.
  3. Participating in reviews, discussions, demonstrations and acceptance testing – I have written a few lines of code, managed a few projects and teams and tested a few projects in my career. In most of those cases a business facing product owner and/or user(s) where involved in validating and verifying the work as it progressed toward completion. I can’t count the number of defects or poor assumptions that were caught and fixed along the way. In those scenarios where real stakeholders did not participate in reviewing, refining and testing the product, the quality was generally lower. Colleagues over the years have expressed similar observations.

When you look in a cube and see a developer or tester reading a user story or use case while typing out a test or perhaps even executing a specific test, it might seem that testing is a solitary event. But you would probably be wrong. What you would have missed is the interaction between developers, testers, product owners that preceded those events, in which knowledge and perspectives were shared. You would have also missed the involvement of users, product owners, developers and stakeholders to review the results so that what gets delivered is not only technically correct, but also has business value. Without involvement, testing provides far less value than possible.


Categories: Process Management

Five Problems That Impact Testing Effectiveness and Efficiency: #1 Planning

 

Forewarned is forearmed!

Forewarned is forearmed!

Testing is an important set of tools for influencing the quality of the functionality that gets delivered. The term testing can cover a wide range of activities ranging from reviews to user acceptance testing with a nearly infinite number of stops in between. Some organizations expend up to 60 – 70% of project effort just on testing (this is abnormally high), often with the intention of “testing in” quality. When the effectiveness and efficiency of testing has been derailed there are five typical root causes.

  • Planning
  • Involvement
  • Organizational Management
  • Capability
  • Process

Planning is the first of the root causes. Poor planning will yield poor results. Test planning defines the approach a project will use to verify and validate the deliverable they are creating. There are several inputs that impact and shape a test plan. The inputs are:

  1. Risk – Risk is a reflection of possibilities that might impact the project if they occur. Some projects will inherently have a bigger impact on the organization if things go wrong. Testing can be tuned to act as insurance that risks do not become issues. Agile projects use a wide range of techniques to incorporate risk into how testing is approached. Planning techniques include release planning, sprint planning, tools like the definition of done, techniques such as test first development (including test driven development) or classic test planning documentation.
  2. Test Goals – Test goals reflect an organization’s business strategy and needs. Test goals can be as simple as ensuring software is defect free (this is not only simple, but a simplistic) to improving the product’s delivered quality (as compared to a standard or a baseline).
  3. Test Policy – A policy defines a course of action that supports a long-term purpose. A test policy describes the type of behavior without defining the ends, means or approach. Good policies are aligned with the business strategy and the test goals. Test policies must be agreed upon (at least passively) by all of the stakeholders.  Policies that the involved parties don’t agree with will potentially generate poor behavior as stakeholders struggle against what they perceive as artificial constraints. For example a policy that requires all applications to be stress tested even if they are standalone, one person applications will not be perceived as fitting the environment.  The policy will be ignored when practitioners don’t think it applies which opens the door for failure if something is not stress tested that should be.
  4. Test Strategy – At an organizational level, a test strategy represents a broad outline that will orperationalize the test policy.At a project level, a test strategy will define the how the project will conform to the test policy and meet the test goals. The strategy operationalizes the testing goals and policies based on the business and project risks.

The typical image painted when discussing test planning is an omnibus document that defines how a project will approach testing, sometimes in mind-numbing detail. While that level of detail might be important in some scenarios, in most Agile projects the adoption of standard techniques provides the policy, strategy and guidance to ensure a good test planning. Agile techniques that improve planning include:

  1. Well-formed user stories (including acceptance criteria),
  2. Test first development (such as test driven development or acceptance test driven development), and
  3. A solid definition of done.

Planning is requirement for any activity development activity, testing included.  Good planning is a requirement for good testing.


Categories: Process Management

Agile Analysis, Self-Selecting Teams, TDD & BDD in Methods & Tools Winter 2014 issue

From the Editor of Methods & Tools - Mon, 12/22/2014 - 15:22
Methods & Tools – the free e-magazine for software developers, testers and project managers – has just published its Winter 2014 issue that discusses Agile Analysis, Self-Selecting Teams,Collaborative Development of Domain-specific Languages, TDD with Mock Objects, BDDfire. Methods & Tools Winter 2014 contains the following articles: * Analysis on Analysts in Agile * Self-Selecting Teams – Why You Should Try Self-selection * Collaborative Development of Domain-specific Languages, Models and Generators * TDD with Mock Objects: Design Principles and Emergent Properties * BDDfire: Instant Ruby-Cucumber Framework 55 pages of software development knowledge that you can freely download from ...

SPaMCAST 321 -11 Reasons For Agile Success, Communication, and Cloud Development

www.spamcast.net

http://www.spamcast.net

 

Listen to the podcast

SPaMCAST 321 features our essay on the reasons for success with Agile.  I asked friends and colleagues what they think are the top reasons an organization succeeds with Agile.  The answers were not always what I expected. We review the top 11 factors leading to success with Agile. Listen and share your feedback.

This episode also includes the next installment of Jo Ann Sweeney’s new column Explaining Change.  Jo Ann discusses whether communication always adds value to a project. Visit Jo Ann’s website at http://www.sweeneycomms.com/ and let her know what you think of her new column.

The third segment of this podcast is a new installment of the Software Sensei, where Kim Pries shines light on the area of cloud development. Development for cloud computing is red hot. Understand the nuances that developing for the cloud to enhance your effectiveness!

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

The next Software Process and Measurement Cast will feature our interview with Clareice and Clyneice Chaney. Clareice and Clyneice provide insights and practical advice into how Agile and contracting can work together.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.


Categories: Process Management

SPaMCAST 321 -11 Reasons For Agile Success, Communication, and Cloud Development

Software Process and Measurement Cast - Sun, 12/21/2014 - 23:00

SPaMCAST 321 features our essay on the reasons for success with Agile.  I asked friends and colleagues what they think are the top reasons an organization succeeds with Agile.  The answers were not always what I expected. We review the top 11 factors leading to success with Agile. Listen and share your feedback.

This episode also includes the next installment of Jo Ann Sweeney’s new column Explaining Change.  Jo Ann discusses whether communication always adds value to a project. Visit Jo Ann’s website at http://www.sweeneycomms.com/ and let her know what you think of her new column.

The third segment of this podcast is a new installment of the Software Sensei, where Kim Pries shines light on the area of cloud development. Development for cloud computing is red hot. Understand the nuances that developing for the cloud to enhance your effectiveness!

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

The next Software Process and Measurement Cast will feature our interview with Clareice and Clyneice Chaney. Clareice and Clyneice provide insights and practical advice into how Agile and contracting can work together.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management

Re-read Saturday: Communicating the Change Vision, Leading Change, John P. Kotter Chapter Six

Communicate, many ways and many times!

Communicate, many ways and many times!

Change is a fact of life. John P. Kotter’s book, Leading Change, defines his famous eight-stage model for change. The first stage of the model is establishing a sense of urgency. A sense of urgency provides the energy and rational for any large, long-term change program. Once a sense of urgency has been established, the second stage in the eight-stage model for change is the establishment of a guiding coalition. If a sense of urgency provides energy to drive change, a guiding coalition provides the power for making change happen. A vision, built on the foundation of urgency and a guiding coalition, represents a picture of a state of being at some point in the future. Once a vision has been established, it must be clearly and consistently communicated. Failure to effectively communicate the vision will cripple change.

Kotter lists seven attributes for effective communication of the change vision.

  1. Keep it simple – The vision must be clearly understandable by all of those who are impacted. The message must be clear and simple, which means ZERO mumbo jumbo. The United States Coast Guard has the one of best vision statements I have ever read, “The world’s best responders: any time, any place, any hazard.” Everyone from top most senior officers to the most junior enlisted personnel would have difficulty misinterpreting the vision when making day-to-day decisions.
  2. Metaphor, analogy and examples –Use words to paint pictures in people’s mind that clarify the complexity.
  3. Multiple forums – Increasing the number of vehicles used to communicate the message increases the chance that the vision will be heard, internalized and institutionalized.
  4. Repetition – Communicating a vision requires more than a roll-out speech and an article in the company newsletter. The vision needs to be continually repeated and reinforced in order to break through the clutter of competing communication.
  5. Leadership by example – Leaders must participate in and live the change. Living the change increases the credibility and deflects resistance. Perceived inconsistencies between the vision of change and how leadership acts will be noticed. Inconsistencies in behavior will hurt or deflect change.
  6. Explain perceived inconsistencies (that need to exist) [HUH?]
  7. Give and take – Communicating the vision for change requires two-way communication between leaders and others involved in making change a reality. Two-way communication means both listening and being heard. Communication implies that if the vision is wrong that the change vision may need to change.

Effective change requires that enough people understand the change they are being asked to make and where that change will lead them. Ambiguously crafted visions and communications will at best cause confusion and at worst derail change. Regardless of the urgent need for a change or how carefully the vision is crafted and even if you have an army of powerful backers, people do not follow those they feel are on the wrong path. [RUN ON] Effective communication of the change vision helps to build the critical mass needed to make change actually happen.


Categories: Process Management

Training Strategies for Transformations and Change: Synthesis

Different training tools are sometimes needed!

Different training tools are sometimes needed!

Organizational transformations, like an Agile transformation, require the acquisition of new skills and capabilities. Gaining new skills and capabilities in an effective manner requires a training strategy. The best transformations borrow liberally from all categories of training strategies to best meet the needs of the transformation program and the culture of the organization. The four major training strategies typically used in Agile (and other IT) transformations have their own strengths and weaknesses. Those attributes make the strategies better for some types of knowledge and skill distribution than other strategies.

Training strategies by use.

Training strategies by use.

Lectures and presentations are the ubiquitous feature of the 21st century corporate meeting. These techniques are useful for spreading awareness and, to a lesser extent, to introduce concepts. The reduced efficiency of the lecture to introduce concepts is a due to trainers that are not trained educators, conference/training rooms that are not as well appointed as college lecture halls and learners that tend to pay only partial attention whenever possible. The partial attention problem is a reflection of email and text messages generated from their day job. Difficulties occur when distributed meetings are not supported with proper telecommunications.

Active learning and experiential learning are both excellent strategies for building and supporting skills and capabilities. Each method can include games, activities, discussions and lecture components. The combination of methods for generating and conveying knowledge keeps the learners focused and involved. Involvement helps defeat the common problem of partial attention by keeping the learners busy. The scalability of the two techniques differs, which can lead to a decision to favor one technique over the other. Many transformation programs blend both strategies. For example, I recently observed a program with group learning session (active learning) with assignments to be done outside the class as part of the learner’s day-to-day activities then debriefed in community of practice sessions (experiential learning).

Mentoring is a specialized form of experience-based learning. Because mentoring is generally a one-on-one technique, it is generally not scalable to for large-scale change programs, however it a good tool to transfer knowledge from one person to another and an excellent tool to support and maintain capabilities. Mentoring is most often used for specialized skills rather than general skills that need to broadly distributed.

Transformation programs generally will need to use more than one training strategy. Each strategy makes sense for specific scenarios. The of crafting an overall strategy requires understanding of which skills, capabilities and knowledge need to be fostered or built within the organization, then the distribution of the learners, the tools available and finally the organization’s culture. Once you understand the requirements, the training strategy can be crafted using a mixture of the training techniques.


Categories: Process Management

Swift self reference in inner closure

Xebia Blog - Fri, 12/19/2014 - 13:06

We all pretty much know how to safely use self within a Swift closure. But have you ever tried to use self inside a closure that's inside another closure? There is a big chance that the Swift compiler crashed (Xcode 6.1.1) without giving you an error in the editor and without any error message. So how can you solve this problem?

The basic working closure

Before we dive into the problem and solution, let's first have a look at a working code sample that only uses a single closure. We can create a simple Swift Playground to run it and validate that it works.

class Runner {
    var closures: [() -> ()] = []

    func doSomethingAsync(completion: () -> ()) {
        closures = [completion]
        completion()
    }
}

class Playground {

    let runner = Runner()

    func works() {
        runner.doSomethingAsync { [weak self] in
            self?.printMessage("This works") ?? ()
        }
    }

    func printMessage(message: String) {
        println(message)
    }

    deinit {
        println("Deinit")
    }

}

struct Tester {
    var playground: Playground? = Playground()
}

var tester: Tester? = Tester()
tester?.playground?.works()
tester?.playground = nil

The doSomethingAsync method takes a closure without arguments and has return type Void. This method doesn't really do anything, but imagine it would load data from a server and then call the completion closure once it's done loading. It does however create a strong reference to the closure by adding it to the closures array. That means we are only allowed to use a weak reference of self within our closure. Otherwise the Runner would keep a strong reference to the Playground instance and neither would ever be deallocated.

Luckily all is fine and the "This works" message is printed in our playground output. Also a "Deinit" message is printed. The Tester construction is used to make sure that the playground will actually deallocate it.

The failing situation

Let's make things slightly more complex. When our first async call is finished and calls our completion closure, we want to load something more and therefore need to create another closure within the outer closure. We add the method below to our Playground class. Keep in mind that the first closure doesn't have [weak self] since we only reference self in the inner closure.

func doesntWork() {
    weak var weakRunner = runner
    runner.doSomethingAsync {

        // do some stuff for which we don't need self

        weakRunner?.doSomethingAsync { [weak self] in
            self?.printMessage("This doesn't work") ?? ()
        } ?? ()
    }
}

Just adding it already makes the compiler crash, without giving us an error in the editor. We don't even need to run it.

Screen Shot 2014-12-19 at 10.30.59

It gives us the following message:

Communication with the playground service was interrupted unexpectedly.
The playground service "com.apple.dt.Xcode.Playground" may have generated a crash log.

And when you have such code in your normal project, the editor also doesn't give an error, but the build will fail with a Swift Compiler Error without clear message of what's wrong:
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc failed with exit code 1

The solution

So how can we work around this problem. Quite simple actually. We simply need to move the [weak self] to the most outer closure.

func doesWork() {
    weak var weakRunner = runner
    runner.doSomethingAsync { [weak self] in

        weakRunner?.doSomethingAsync {
            self?.printMessage("This now works again") ?? ()
        } ?? ()
    }
}

This does mean that it's possible that within the outer closure, self is not nil and in the inner closure it is nil. So don't write code like this:

    runner.doSomethingAsync { [weak self] in

        if self != nil {
            self!.printMessage("This is fine, self is not nil")

            weakRunner?.doSomethingAsync {
                self!.printMessage("This is not good, self could be nil now")
            } ?? ()
        }
    }

There is one more scenario you should be aware of. If you use an if let construction to safely unwrap self, you could create a strong reference again to self. The following sample illustrates this and will create a reference cycle since our runner will create a strong reference to the Playground instance because of the inner closure.

    runner.doSomethingAsync { [weak self] in

        if let this = self {

            weakRunner?.doSomethingAsync {
                this.printMessage("Captures a strong reference to self")
            } ?? ()
        }
    }

Also this is solved easily by including a weak reference to the instance again, now called this.

runner.doSomethingAsync { [weak self] in

    if let this = self {

        weakRunner?.doSomethingAsync { [weak this] in
            this?.printMessage("We're good again") ?? ()
        } ?? ()
    }
}
Conclusion

Most people working with Swift know that there are still quite a few bugs in it. In this case, Xcode should give us an error in the editor. If your editor doesn't complain, but your Swift compiler fails, look for closures like this and correct it. Always be safe and use [weak self] references within closures.

Training Strategies for Transformations and Change: Experiential Learning

You learn to play an instrument by practicing.

You learn to play an instrument by practicing.

Experiential learning, often thought of as learning by doing, can play an important role in any transformation program. In this strategy learners gather knowledge from the combination of doing something, reflecting on what was done and finally generalizing learnings into broader knowledge. The theory holds that knowledge is internalized through concrete engagement more effective and quickly rather through rote learning techniques. The basic steps of experiential learning are:

Experience – The learner is directly involved in experiences that are tied to a real world scenario. The teacher facilitates the experience. Writing your first computer program in a computer lab is an example of a concrete learning experience.

Reflection – The learner reflects on what happened and what they learned during the experience. Reflection typically includes determining what was important about the experience for future experiences. When used in a classroom, the reflection step generally includes sharing reflections and observations with the classmates (a form of a feedback loop). Demonstrating the program you wrote, reviewing the code snippets and sharing lessons learned with the class would be an example of this step.

Generalization – The learner incorporates the experience and what was learned into their broader view of how their job should be performed. The lessons learned from writing the program adds to the base of coding and problem-solving knowledge for the learner.

The flow of work through a team using Scrum can be mapped to experiential learning model. Small slices are of work are accepted into a sprint, the team solves the business problem, reflects on what was learned and then uses what was learned to determine what work will be done next. The process follows the experience, reflection, generalization flow.

There are several versions of the three stage experiential learning model. Conceptually they are all similar, the differences tend to be how the stages are broken down. For example, Northern Illinois University breaks the reflection step into reflection and “what’s important” steps.

There are several pluses and minuses I have observed in applying experiential learning in transformation programs.

Pluses

  1. Builds on and connects theory to the real world – Theory is often a dirty word in organizations. Experiential learning allows learners to experience a concept that can then be tied back to higher-level concepts such as theory.
  2. Experiences can be manufactured – Meaningful real-life examples can be designed to generate or focus on a specific concepts. When I learned to code first assembler computer program in the LSU computer lab, I was assigned a specific project by my TA.  This was an example of experiential learning.
  3. Can be coupled with other learning techniques – Experiential learning techniques can be combined with other learning strategies to meet logistical and cultural needs. For example classic lecture methods can be combined with experiential learning. My assembler class at LSU included lecture (theory) and lab (experiential) features.
  4. Individuals can apply experiential learning outside of the classroom – Motivated learners often apply the concept of experiential learning to add skills in a non-classroom environment when the skill may not generally applicable to the team or organization. For example, I had an employee learn to write SQL when I got frustrated waiting for the support team to write queries for him.  I learned by writing simple queries and debugging the results (he also used the internet for reference).

Minuses

  1. Not perfectly scalable – Experiential learning in the classroom or organization tends to require facilitation. Facilitation of large groups either requires multiple facilitators for breaking the group up into smaller groups and extending the time it takes to deliver the training. Without good facilitation experiential learning is less effective (just ask my wife about my skills facilitating her experience learning to drive a stick shift).
  2. Requires careful design – Experience, if not designed or facilitated well, can lead to learning the wrong lesson or to failures that impact the learner’s motivation.
  3. Reflection and generalization steps are often overlooked – The steps after experience are occasionally not given the focus needed to draw out concepts that were learned and then allow them to be incorporated the broader process of how work is performed.

Can anyone learn to ride a bicycle from a book or from a lecture? But you can learn to ride a bicycle using experiential learning (the reality is that it might be the only way). Experiential learning lets the learner try to ride the bike, fall and skin their knees, reflect on the how to improve and then try again.


Categories: Process Management

Training Strategies for Transformations and Change: Active Learning

Group discussion is an active learning technique.

Group discussion is an active learning technique.

Change is often premised on people learning new methods, frameworks or techniques.  For any change to be implemented effectively, change agents need to understand the most effective way of helping learners learn.  Active learning is a theory of teaching based on the belief that learners should take responsibility for their own learning.  Techniques that support this type of teaching exist on a continuum that begins with merely fostering active listening, to interactive lectures and finally to using investigative inquiry techniques. Learning using games is a form of active learning (see www.tastycupcake.org for examples of Agile games).  Using active learning requires understanding the four basic elements of active learning, participants’ responsibilities and keys to success.

There are four basic elements of active learning that need to be worked into content delivery.

  1. Talking and listening – The act of talking about a topic helps learners organize, synthesize and reinforce what they have learned.
  2. Writing – Writing provides a mechanism for students to process information (similar to talking and listening). Writing is can used in when groups are too large for group or team level interaction or are geographically distributed.
  3. Reading – Reading provides the entry point for new ideas and concepts. Coupling reading with other techniques such as writing (e.g. generating notes and summaries) improves learner’s ability to synthesize and incorporate new concepts.
  4. Reflecting – Reflection provides learners with time to synthesize what they have learned. For example providing learners with time to reflect on how they would teach or answer questions on the knowledge gained in a game or exercise helps increase retention.

Both learners and teachers have responsibilities when using active learning methods. Learners have the responsibility to:

  1. Be motivated – The learner needs to have a goal for learning and be will to expend the effort to reach that goal [HUH?]
  2. Participate in the community – The learner needs to other learners in games, exercises and discussions. [HUH?]
  3. Be able to accept, shape and manage change – Learning is change; the learner must be able to incorporate what they have learned into how they work.

While by definition, active learning shifts the responsibility for learning to learner not all of the responsibility rests on the learner. Teachers/Organization have the responsibility to:

  1. Set goals – The teacher or organization needs to define or identify the desired result of the training.
  2. Design curriculum – The trainer (or curriculum designer) needs to ensure they have designed the courseware needed to guide the learner’s transformations.
  3. Provide facilitation – The trainer needs to provide encouragement and help make the learning process easier.

As a trainer in an organization pursuing a transformation, there are several keys to successfully using active learning.

  1. Use creative events (games or other exercised) that generate engagement.
  2. Incorporate active learning in a planned manner.
  3. Make sure the class understands the process being used and how it will benefit them.
  4. In longer classes, vary pair, team or group membership to help expose learners to as diverse a set of points-of-view as possible.
  5. All exercises should conclude with a readout/presentation of results to the class.  Varying the approach (have different people present, ask different questions) taken during the readout help focus learner attention.
  6. Negotiate a signal for students to stop talking. (Best method: The hand raise, where when the teacher raises his or her hand everyone else raises their hand and stops talking.)

While randomly adding a discussion exercise at the end of a lecture module uses an active learning technique, it not a reflection of an effective approach to active learning.  When building a class or curriculum that intends to use active learning, the game and exercises that are selected need to be carefully chosen  to illicit the desired learning impact.


Categories: Process Management

Training Strategies for Transformations and Change

Presentations are just one learning strategy.

Presentations are just one learning strategy.

How many times have you sat in a room, crowded around tables, perhaps taking notes on your laptop or maybe doing email while someone drones away about the newest process change? All significant organizational transformations require the learning and adoption of new techniques, concepts and methods. Agile transformations are no different. For example, a transformation from waterfall to Scrum will require developing an understanding of Agile concepts and Scrum techniques. Four types of high-level training strategies are often used to support process improvement, such as Agile transformations. They are:

  1. Classic Lecture /Presentation – A presenter stands in front of the class and presents information to the learners. In most organizations the classic classroom format is used in conjunction with a PowerPoint deck, which provides counterpoint and support for the presenter. The learner’s role is to take notes from the lecture, interactions between the class and presenter and the presentation material and then to synthesize what they have heard. Nearly everyone in an IT department is familiar with type of training from attending college or university. An example in my past was Psychology 101 at the University of Iowa with 500+ of my closest friends. I remember the class because it was at 8 AM and because of the people sleeping in the back row. While I do not remember anything about the material many years later, this technique is often very useful in broadly introducing concepts. This method is often hybridized with other strategies to more deeply implement techniques and methods.
  2. Active Learning – Is strategy that is based on the belief that learners should take responsibility for their own learning. Learners are provided with a set of activities that keep them busy doing what is to be learned while analyzing, synthesizing and evaluating. Learners must do more than just listen and take notes. The teacher acts as a facilitator to help ensure the learning activities include techniques such as Agile games, working in pairs/groups, role-playing with discussion of the material and other co-operative learning techniques. Active learning and lecture techniques are often combined.
  3. Experiential Learning – Experiential learning is learning from experience. The learner will perform tasks, reflect on performance and possibly suffer the positive or negative consequences of making mistakes or being successful. The theory behind experiential learning is that for learning to be internalized the experience needs to be concretely and actively engaged rather than in a more theoretical or purely in a reflective manner. Process improvement based on real time experimentation in the Toyota Production system is a type of experiential learning.
  4. Mentoring – Mentoring is a process that uses one-on-one coaching and leadership to help a learner do concrete tasks with some form of support. Mentoring is a form of experience based learning, most attributable to the experiential learning camp. Because mentoring is generally a one-on-one technique it is generally not scalable to for large-scale change programs.

The majority of change agents have not been educated in adult learning techniques and leverage classic presentation/lecture techniques spiced with exercises. However, each of these high-level strategies have value and can be leveraged to help build the capacity and capabilities for change.


Categories: Process Management

5 Reasons Product Owners Should Let Teams Work Out of Order

Mike Cohn's Blog - Tue, 12/16/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

A product owner hands 10 story cards to the team. The team reads them and hands the fifth and sixth cards back to the product owner. By the end of the sprint, the team delivers the functionality described on cards 1, 2, 3, 4, and 7. But the team has not touched the work of cards 5 and 6.

And I say this is OK.

Standard agile advice is that a team should work on product backlog items in the order prescribed by the product owner. And although this is somewhat reasonable advice, I want to argue that good agile teams violate that guideline all the time.

There are many good reasons for a team to work out of order. Let’s consider just a few, and consider it sufficient evidence that teams should be allowed to work out of order.

1. Synergies

There are often synergies between items near the top of a product backlog—while a team is working on item No. 3, they should be allowed to work on No. 6. If two items are in the same part of the system and can be done faster together than separately, this is usually a good tradeoff for a product owner to allow.

2. Dependencies

A team may agree that No. 4 is more important than No. 5 and No. 6 on the product backlog. Unfortunately, No. 4 can’t be done until No. 7 has been implemented. Finding a dependency like this is usually enough to justify a team working a bit out of the product owner’s prioritized sequence.

3. Skillset Availability

A team might love to work on the product owner’s fourth top priority, but the right person for the job is unavailable. Sure, this can be a sign that additional cross-training is needed on that team to address this problem – but, that is often more of a long-term solution. And, in the short term, the right thing to do might simply be to work a bit out of order on something that doesn’t require the in-demand skillset.

4. It’s More Exciting

OK, this one may stir up some controversy. I’m not saying the team can do 1, 2, 3, 4, and then number 600. But, in my example of 1, 2, 3, 4 and 7, choosing to work on something because it’s more exciting to the team is OK.

On some projects, teams occasionally hit a streak of product backlog items that are, shall we say, less than exciting. Letting the team slide slightly ahead sometimes just to have some variety in what they’re doing can be good for the morale of the team. And that will be good for product owners.

Bonus Reason 4a: It’s More Exciting to Stakeholders

While on the subject of things being more exciting, I’m going to say it is also acceptable for a team to work out of order if the item will be more exciting to stakeholders.

It can sometimes be a challenge to get the right people to attend sprint reviews. It gets especially tough after a team runs a few boring ones in a row. Sometimes this happens because of the nature of the high-priority work—it’s stuff that isn’t really visible or is esoteric perhaps to stakeholders.

In those cases, it can be wise to add a bit of sex appeal to the next sprint review by making sure the team works on something stakeholders will find interesting and worth attending the meeting for.

5. Size

In case the first four (plus) items haven’t convinced you, I’ve saved for last the item that proves every team occasionally works out of product owner order: A team may skip item 5 on the product backlog because it’s too big. So they grab the next one that fits.

If a team were not to do this, they would grab items 1, 2, 3, and 4 and stop, perhaps leaving a significant portion of the sprint unfilled. Of course, the team could look for a way to perhaps do a portion of item 5 before jumping down to grab number 7. But sometimes that won’t be practical, which means the team will at least occasionally work out of order.

Product Owners Aren’t Perfect

A perfect product owner would know everything above. The perfect product owner would know that the team’s DBA will be full from tasks from the first four product backlog items, and so wouldn’t put a database-intensive task fifth. The perfect product owner would know that items 2 and 5 both affect the same Java class, and would naturally prioritize them together.

But most product owners have a hard time being perfect. A better solution is for them to put the product backlog in a pretty good prioritized order, and then leave room for fine tuning from the team.

What do you do when inertia wins?

Step 3 is to take smaller bites!

Step 3 is to take smaller bites!

Changing how any organization works is not easy.  Many different moving parts have to come together for a change to take root and build up enough inertia to pass the tipping point. Unfortunately because of misalignment, misunderstanding or poor execution, change programs don’t always win the day.  This is not new news to most of us in the business.  What should happen after a process improvement program fails?  What happens when the wrong kind of inertia wins?

Step One:  All failures must be understood.

First, perform a critical review of the failed program that focuses on why and how it failed.  The word critical is important.  Nothing should be sugar coated or “spun” to protect people’s feelings.  A critical review must also have a good dose of independence from those directly involved in the implementation.  Independence is required so that the biases and decisions that led to the original program can be scrutinized.  The goal is not to pillory those involved, but rather to make sure the same mistakes are not repeated.  These reviews are known by many names: postmortems, retrospectives or troubled project reviews, to name a few.

Step two:  Determine which way the organization is moving.

Inertia describes why an object in motion tends to stay in motion or those at rest tend to stay at rest.  Energy is required to change the state of any object or organization; understanding the direction of the organization is critical to planning any change. In process improvement programs we call the application of energy change management.  A change management program might include awareness building, training, mentoring or a myriad of other events all designed to inject energy into the system. The goal of that energy is either to amplify or change the performance of some group within an organization.  When not enough or too much energy is applied, the process change will fail.

Just because a change has failed does not mean all is lost.  There are two possible outcomes to a failure. The first is that the original position is reinforced, making change even more difficult.  The second is that the target group has been pushed into moving, maybe not all the way to where they should be or even in the right direction, but the original inertia has been broken.

Frankly, both outcomes happen.  If the failure is such that no good comes of it, then your organization will be mired in the muck of living off past performance.  This is similar to what happens when a car gets stuck in snow or sand and digs itself in.  The second scenario is more positive, and while the goal was not attained, the organization has begun to move, making further change easier.  I return to the car stuck in the snow example.  A technique that is taught to many of us that live in snowy climates is “rocking.” Rocking is used to get a car stuck in snow moving back and forth.  Movement increases the odds that you will be able to break free and get going in the right direction.

Step Three:  Take smaller bites!

The lean startup movement provides a number of useful concepts that can be used when changing any organization.  In Software Process and Measurement Cast 196, Jeff Anderson talked in detail about leveraging the concepts of lean start-ups within change programs (Link to SPaMCAST 196).  A lean start up will deliver a minimum amount of functionality needed to generate feedback and to further populate a backlog of manageable changes. The backlog should be groomed and prioritized by a product owner (or owners) from the area being impacted by the change.  This will increase ownership and involvement and generate buy-in.  Once you have a prioritized backlog, make the changes in a short time-boxed manner while involving those being impacted in measuring the value delivered.  Stop doing things if they are not delivering value and go to the next change.

Being a change agent is not easy, and no one succeeds all the time unless they are not taking any risks.  Learn from your mistakes and successes.  Understand the direction the organization is moving and use that movement as an asset to magnify the energy you apply. Involve those you are asking to change to building a backlog of prioritized minimum viable changes (mix the concept of a backlog with concepts from the lean start up movement).  Make changes based on how those who are impacted prioritize the backlog then stand back to observe and measure.  Finally, pivot if necessary.  Always remember that the goal is not really the change itself, but rather demonstrable business value. Keep pushing until the organization is going in the right direction.  What do you do when inertia wins?  My mother would have said just get back up, dust your self off and get back in the game.


Categories: Process Management

SPaMCAST 320 – Alfonso Bucero – Today is a Good Day

www.spamcast.net

http://www.spamcast.net

 

Listen to the Software Process and Measurement Cast 320

SPaMCAST 320 features our interview with Alfonso Bucero. We discussed his book, Today Is A Good Day. Attitude is an important tool for a project manager, team member or executive.  In his book Alfonso provides a plan for honing your attitude.

Alfonso Bucero, MSc, PMP, PMI-RMP, PMI Fellow, is the founder and Managing Partner of BUCERO PM Consulting.  He managed IIL Spain for almost two years, and he was a Senior Project Manager at Hewlett-Packard Spain (Madrid Office) for thirteen years.

Since 1994, he has been a frequent speaker at International Project Management (PM) Congresses and Symposiums. Alfonso has delivered PM training and consulting services in Spain, Mexico, UK, Belgium, Germany, France, Denmark, Costa Rica, Brazil, USA, and Singapore. As believer in Project Management, he teaches that Passion, Persistence and Patience as keys for project success.

Alfonso co-authored the book Project Sponsorship with Randall L. Englund published by Josse-Bass in 2006. He has authored the book Today is a Good Day – Attitudes for achieving project success, published by Multimedia Publishing in Canada in 2010. He has also contributed to professional magazines in Russia (SOVNET), India (ICFAI), Argentina and Spain. Alfonso co-authored The Complete Project Manager and The Complete Project Manager Toolkit published with Randall L. Englund published by Management Concepts in March 2012. Alfonso published The Influential Project Manager in 2014 with CRC Press in the US.

Alfonso has also published several articles in national and international Project Management magazines. He is a Contributing editor of PM Network (Crossing Borders), published by the “Project Management Institute”.

Contact Alfonso: alfonso.bucero@abucero.com
Twitter:
@abucero
Website: http://www.abucero.com/

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

In the next Software Process and Measurement Cast we will feature our essay on the requirements for success with Agile.  Senior management, engagement, culture and coaches are components but not the whole story

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST
Register Now

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.


Categories: Process Management