SPaMCAST 320 – Alfonso Bucero – Today is a Good Day

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 8^th.  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.

 

Project Sponsor Anti-patterns

Some Anti-Patterns Should Be Avoided

Wikipedia describes an anti-pattern as a response to a typical problem that is ineffective or potentially counterproductive. There are numerous ways to implement project sponsorship that work (patterns) and just as many that don’t work (anti-patterns). Reviewing the four of the most typical anti-patterns and some ideas on how to mitigate the negative impact is illustrative of the problems teams and organizations face.

1. Absentee Sponsor: If you have not seen or talked to your sponsor in recent memory you are dealing with the problem of an absentee sponsor. Absentee sponsors can occur for a number of reasons including a project without an identified sponsor, a sponsor that is overburdened or an uninterested sponsor. Each specific cause requires a slightly different course of action; however the underlying cause generally is a problem of portfolio management. In many cases these problems are a reflection of starting more projects than the organization can work on effectively at one time. By starting too many projects the organization will struggle to either find sponsors that are directly interested in the project or can spend the time needed. One organization I worked with required a commitment to engage by a business sponsor before they would consider a project. Sponsors provide influence and resources needed by a project to be effective. Projects that fail this basic hurdle should be postponed. If an active project is suffering from an absentee sponsor, the project lead should, at the very least, escalate the issue as a critical risk as high up in organizational hierarchy as possible.
2. Underpowered Sponsor: Underpowered sponsors can’t provide enough support, influence or resources for the project to effectively and efficiently deliver value. Underpowered sponsors usually are caused by two situations: The first, like absentee sponsors, is a reflection of a portfolio issue. The second issue is often a reflection of someone new to the ranks of senior management or the ranks of being a sponsor. The simplest solution to the second issue is for the “underpowered sponsor” to find an organizational ally (or allies) to augment their organizational power. A more radical solution would be to replace the underpowered sponsor; however, this should be a last resort solution and only used for critical projects.
3. Proxy Sponsor: A proxy sponsor is a stand-in for the person that should be the sponsor. Proxy sponsors occur for many of the same reasons as absentee or underpowered sponsors; however, in this case someone has recognized the problem and tried to patch the problem. In many cases the “real” sponsor has delegated the responsibility for sponsorship either to IT or to his/her direct report. Decision-making in projects with proxy sponsors will take longer and will typically suffer from more interruptions from higher priority activities. Projects in this scenario should seek to identify decisions and support needs that are outside of the team’s span of control as early possible and avoid waiting for the escalation and validation process to catch up. One solution I suggest is that the proxy schedule periodic meetings which a more senior sponsor (a decision-maker) to ensure the wait time for decisions to be made is minimized.
4. Role Conflict: Sponsors should not be project managers, Scrum masters or product owners. Occasionally, sponsors are seduced to the dark side and attempt to play one or more of these roles. Usually when a sponsor tries to play any of these roles on top of being the project sponsor (and in addition to their day job) they will be overwhelmed. In most cases the project leader should discuss the problem with the sponsor and ensure they have the proper training need to effectively act as a sponsor.

Effective project sponsorship is critical for any project to deliver the value described in project’s business case. The anti-patterns are most often a reflection of the poor portfolio management. Starting too many projects at once slows all projects down and typically means less gets done than if a more measured approach were taken. A project should not be started unless the right sponsor (which includes making sure they are trained to be a sponsor) is identified and they agree to take on the role. The right sponsor will be able to provide the right level of interest, influence and resources. Any other solution might help but will not solve the problem in the long run!

 

SPaMCAST 303 – Topics in Estimation, Software Sensei, Education

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 303

Software Process and Measurement Cast number 303 features our essay titled “Topics in Estimation.” This essay is a collection of smaller essays that cover wide range of issues effecting estimation.  Topics include estimation and customer satisfaction, risk and project estimates, estimation frameworks and size and estimation.  Something to help and irritate everyone, we are talking about estimation – what would you expect?

We also have a new installment of Kim Pries’s Software Sensei column.  In this installment Kim discusses education as defect prevention.  Do we really believe that education improves productivity, quality and time to market?

Listen to the Software Process and Measurement Cast 303

Next

Software Process and Measurement Cast number 304 will feature our long awaited interview with Jamie Lynn Cooke, author The Power of the Agile Business Analyst. We discussed the definition of an Agile business analyst and what they actually do in Agile projects.  Jamie provides a clear and succinct explanation of the role and value of Agile business analysts.

Upcoming Events

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60^th Conference October 21^st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

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.

 

Project Charters

This team is eager to begin work on its charter.

Project charters play an extremely important role in the initiation of projects.  The Project Management Institute (PMI) suggests that no project should begin without a charter.  A project charter creates a foundation to guide project activities.  The primary roles of the charter are to:

1. Authorize the project to move forward.  In many methodologies the charter acts as the authorizing document.  The charter will include items such as the business need, project scope, budget and the signature of sponsors.  In some organizations the sponsor or the sponsor’s organization will author the document and use it as a form of transmittal or work ticket. While the literature is rich with processes in which the charter is written outside of the development team, I have never seen this process in action.  What is more typical is a charter written by IT and signed-off on by the stakeholders or some sort of electronic budget authorization. Regardless of methodology, in a large organization, an authorization to spend money is important.
2. Acts as a communication vehicle. The charter is often used to capture the initial thoughts of the sponsors, product owner and team about the goals of the project and the rules they will use to govern themselves (or be governed by in classic command and control methodologies).
3. Provide structure for the team. Who is on the project team is not always as evident as it should be.  The charter should identify the team members (and some logistical info, like time zone, if distributed) with the roles they are playing, if needed.  In many IT organizations, team members play specified, specialist roles. While specialization is a feature mainly thought to be seen in organizations using classic development and project management techniques, it can also be seen, albeit to a lesser extent, in organizations using Agile. Depending on the method used the product owner and Scrum Master should also be identified.  Other team attributes such as team norms and expectations should be identified and agreed upon.
4. Identify needed resources. Remember that the resources needed, like business needs and requirements, continually evolve. Therefore over time the charter must evolve or be replaced. For example, a charter I recently reviewed for a new Agile project and team identified the need for a team work room and licenses for a specific automated testing tool.

The macro goal for the charter is to get the project going in the right direction.  The needs and requirements of most projects of moderate to large size/duration are relatively dynamic.   The issue is that while charters are supposed to change and evolve, once they are created they are prone to becoming shelf-ware.

A charter can contain additional information such as risks, constraints, project context and deadlines. The range of data that can be housed in a charter is limitless.  However, I have seem large projects spend months writing and wordsmithing charters that were hundreds of pages long. The process of thinking about all of the charter topics might be valuable, however rarely is the document used after the sponsors and other stakeholders sign off on the document. Whether Agile or a classic plan-based, rarely will the charter see the light of day (or an update cycle) unless the topics covered are important to the team.

 

Rescuing a Trouble Project With Agile: Agile Addresses Tactical and Strategic Project Needs

A rescue makes sense. This kid is miserable.

Projects run into trouble for an infinite number of reasons. Assuming a rescue makes sense, why does applying or reapplying Agile make sense as a rescue technique? Agile can help address all of the more common problems that cause projects to fail.

How would common Agile techniques help address these issues?

Not all of the reasons a project becomes troubled can be addressed. Sometimes the right answer is either to use other rescue techniques or to terminate the project, redeploy the assets and let the people involved do something else. For example, if a true product owner can’t be found or deployed, Agile is not an appropriate rescue technique. A second example, a number of years ago the company I was working for had a project to modify the company’s product delivery methods.  The organization was sold to a competitor that had a different business product model that conflicted with the goal of the project. We spent a month trying to smooth out the clash of goals before shutting the project down.  This was not a project that could or should have been rescued. The assessment step answers two questions. First, can or should the project be rescued. Second, what is causing the project challenges. Once we have idea of what is causing the problems we can decide on whether using Agile to rescue the project makes sense. From there we can decide which Agile techniques should be placed on top of our process improvement backlog.

 

Scrum Master: Facilitator or Enabler?

Don’t just outlaw problems, facilitate a solution.

The difference between facilitating and enabling is at the core of the Agile concept of self-organizing and self-managing teams. An effective scrum master should be a facilitator in a well functioning Agile team. However, when there is a breakdown in a self-organizing and self-managing team, sometimes scrum masters become enablers. This makes scrum masters more like project managers. A facilitator helps to unstick something that has stopped or creates an environment where progress can be made by the team.  An enabler provides the team with permission for making a decision.  For example, I recently watched as a team asked their scrum master if they were allowed to hold an interim show and tell/demonstration to prompt the product owner for feedback. The team saw the scrum master as an enabler rather than a facilitator.

Providing permission to the team to make decisions shifts the risk and from the team to the scrum master.  In the past we had a term for the decision maker role on a team: a project manager. The enabler is someone who sees a logjam and then provides the team with a solution and then ensures that the solution is taken.

On the other hand, a facilitator helps the team to make a decision.  A facilitator uses techniques such as asking questions and then helping the team to listen to the answers. Asking questions helps the team to frame or reframe the issue so that they can develop their own solution. By finding their own solution teams increase their ownership of the solution; it is no longer the project manager’s responsibility to make decisions for the team. For example, when a facilitator observes that a team is having issues working together, he/she will make sure everyone gets their issues on the table during a retrospective. During the retrospective, the facilitator will use a technique that will create an environment that will help the team get to the root cause.  The facilitator will continue to ask probing questions until the team identifies the issues.

In the same scenario, an enabler is apt to present the team with his or her definition of the issue (and potentially with a solution). While providing the problem and solution might seem like a more efficient use of time, it will not provide the team with a learning moment.  In the long run the team will become dependent on the enabler to identify and solve their problems. Having everyone on team learn to identify and solve teams problems leads to less time waiting for someone else to solve problems.

Here’s a quick framework to use in order to decide if you are a facilitator or an enabler:

• Facilitators ask questions. Enablers provide answers.
• Facilitators listen to understand. Enablers listen to act.
• Facilitators help things to happen. Enablers make things happen.
• Facilitators make strong teams. Enablers make strong individuals.

The primary role of a scrum master is that of a facilitator. Making decisions for the team creates a dependency that defeats the whole idea of a self-organizing and self-managing team.  A facilitator makes the team stronger by helping them to learn to make decisions and find their own voice.

 

SPaMCAST 280 – Mark Bojeun, Program Management Leadership

Listen to the Software Process and Measurement Cast 280. SPaMCAST 280 features our interview with Mark C. Bojeun, author of Program Management Leadership: Creating Successful Team Dynamics (Kindle version). Mark makes a very strong case that project and program managers can impact team culture and dynamics. The team’s culture is directly linked to productivity, quality and morale.

Mark’s Bio

Dr. Bojeun has more than 20 years experience in providing strategic management and leadership through portfolio, project and program management. His experience includes developing and managing multi-million dollar portfolios, programs and projects, facilitating the achievement of strategic objectives, and creating best practice processes for program and project management efforts. Dr. Bojeun has designed and implemented multiple Enterprise Program Management Offices (EPMOs) for domestic and multinational firms and has extensive experience in organizational change management through transformational leadership, strategic support and staff empowerment to management professionals in the development and implementation of organizational vision, mission, objectives, and goals.

Dr. Bojeun holds a Program Management Professional (PgMP), Project Management Professional (PMP) and Risk Management (PMI-RMP) certification from the Project Management Institute (PMI), is a Microsoft Certified Solution Developer (MCSD), and has a Bachelor’s degree in Business Administration, an MBA from George Mason University and a PhD in Organizational Leadership.

Dr. Bojeun’s new book, Program Management Leadership: Creating Successful Team Dynamics as part of CRC Publishing’s Best Practices and Advances in Program Management Series addresses the need for effective leadership styles in managing programs and projects achieving high performing teams that consistently exceed expectations.

Over the last ten years, Dr. Bojeun has provided commercial training courses in all aspects of Program and Project management and has been an Adjunct Professor for a number of universities.  Dr. Bojeun is currently an Adjunct Professor at Strayer University where he actively teaches business, logistics and project management courses for both undergraduate as well as graduate students. In addition, he provides motivational presentations to leaders throughout the world.

Contact Mark on LinkedIn or email at mark.bojeun@dc.gov

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay on value chain mapping. Value is generated through the transformation of raw materials into a new form, which is represented by a value chain. Driving effective change requires an understanding of your organization’s value chain.

Upcoming Events

March 18
Agile Philly March Meeting:
I am speaking at Agile Philly’s March 18^th meeting on the topic of Function Points. The meeting begins at 630 PM EST – 830 in King of Prussia, PA – Details at http://www.agilephilly.com/events/function-points

ISMA 9
I will be attending the International Function Point Users Group conference and workshops in Madrid, Spain on March 27^th with workshops on March 25^th and 26^th.
More information

QAIQuest 2014
I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast
I will be speaking at the StarEast Conference May 4th – 9^th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

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.

 

The Top Five SPaMCAST Essays

It is that time of year!  Time to celebrate what worked and what didn’t (and yes I said celebrate what didn’t work – without experimentation there is no growth!) I have compiled the top five essays and top ten interviews from the 2013 ‘ish.  Today we celebrate the essays.  The top five most downloaded essays were:

SPaMCAST 219 – Agile and Risk Management

SPaMCAST 217 – Metrics Minute, Automated Test Cases Passed

SPaMCAST 231 – Metrics Minute, Burden Rate

SPaMCAST 247 – Sprint Reviews and Demonstrations

SPaMCAST 255 – Project Management Is Dead, Pries – Checklists

 

Click on the link to listen to any that may have missed.

The trend I see in these five essays is an interest in advice that can be immediately applied by teams and change agents.

Three of the essays that I got the most out writing that did not make the top five were:

SPaMCAST 263 – Transactional Analysis

SPaMCAST 239 – Commitment

SPaMCAST 251 – Commitment, Revisited

 

These essays were about building base knowledge about how work is done.  These essays were less tactical and more strategic in nature.  Both the tactical and the strategic are needed for a complete picture that benefits teams and change agents.

We are currently counting down the top ten interviews and will provide SPaMCAST listeners and readers with a complete list on 1 January 2013.  I hope your holiday season is meeting your expectations.

Notes:  I complied download statistics for podcast released between 1 December 2012 and 30 November 2013.  SPaMCAST specials, for example the downloadable copy of the SNAP Counting Manual, were not included.

 

Scrum…A Simple Framework: The Roles

IT workers are highly specialized, like the pika is for his habitat.

One of the key features of Scrum is the small number of named roles.  According to Capers Jones, the information technology field has more named specialties than any other profession. In practice this means that individuals are spread across more project teams so they can practice their specialty.  This degree of overspecialization leads to complexity by making the logistics of planning and delivering work more difficult.  Just making sure a the correct specialists are available at the right time can be a nightmare.

The roles of the core team called out by Scrum are:

1. The product owner who represents the voice of the business,
2. The development team that transforms ideas into functionality and
3. The Scrum Master who facilitates the team and process.

Scrum teams work when they have the following common features.

1. Cross-functional teams: the team includes the disciplines needed to accomplish the agreed upon functions.
2. Self-organizing teams: the team decides who does what and how they do it.
3. Self-managing teams: the team uses peer pressure, group consensus and discussion to make sure the work gets done.
4. Business representation: the team includes the business representative.  The business representative acts as the voice of the customer, and even more importantly, the voice of change.
5. Backlog-driven: work is selected from the backlog by the product owner. Sprints build to releases rather than being driven by brittle schedules.

These attributes help teams form boundaries, develop the relationships needed for trust and then to succeed in delivering real business value, forming a virtuous cycle that reinforces team cohesion.

The one role not explicitly identified in Scrum that causes the greatest concern is the project manager.   The common roles of the traditional project manager are:

1. Measurement – How are we doing?
2. Tracking status – Where are we?
3. Reporting – Telling others how things are going.
4. Communication – Are the right people are talking to each other, internally and externally?
5. Risk management – What are the risks and what is to be done if they happen?
6. Process compliance – Are the processes are being followed?

In the Scrum framework all six of these common project management tasks are absorbed by the core team, under the auspices of self-organization and self-management.

IT specialties developed because the knowledge required to perform certain tasks were needed.  Whether that task was development, testing, business analysis or project management, the education and knowledge to perform these tasks are needed by the team.  Specialization that stops team members cross functional creates bottlenecks that reduce productivity and flow.

 

Agile Project Management: The Tipping Point

As a team self-actualizes, the need for command and control management falls.

As organizations transition to Agile, teams often ask about how to transition from classic command and control project methods into self-organizing teams. Self-organizing and self-managing teams do not just appear magically. Both the project teams and the organization have baggage that needs to be rationalized and unlearned to progress from needing to be led to leading themselves. The concepts that need to be learned include: measuring business value, team decision making and to share the real goals of projects.

Classic command and control project management (which I would classify as minimally collaborative) is based on the premise that the project manager has a unique set of skills for project planning, controlling the activities of the team and status reporting. Certifications, like the PMP, have been used to encourage this belief.  In this environment the measures of success for projects are being on-time, on-budget and on-scope.

In Agile projects, as we have discussed in earlier  Daily Process Thoughts, the roles of the classic project manager are spread across the three basic Agile roles (product owner, Scrum Master and the development team). A fourth role, the Agile Program Manager, is needed when multiple projects become a coordinated program.  The primary measures of success in Agile projects are delivered business value and customer satisfaction. (Note: Delivered value and customer satisfaction should be the primary measure of success in ALL types of projects, however these are not generally how project teams are held accountable.)

As teams learn to embrace and use Agile principles they need to learn how to make decisions as a team. The decisions that teams need to learn how to make for themselves have consequences, and they will be wrong sometimes. To accomplish this learning process in the least risky manner, the team should use techniques like delaying decisions as late as is practical and delivering completed work using time boxes. These techniques reduce risk by increasing the time the team has to gather knowledge and to elicit feedback. The organization also must learn how to encourage the team to make good decisions. This requires the organization to accept some level of explicit, initial ambiguity that is caused by delaying decisions, rather than implicit ambiguity of making decisions early that later turn to be wrong. The organization must also learn to evaluate teams and individuals less on the outcome of a single decision and more on the outcome of the value the team delivered.

 Teams also have to unlearn habits, for example, relying on others to plan for them. In order to do that, all leaders and teams must have an understanding of the true goals of the project (listen to my interview with David Marquet) and how the project fits into the strategic goals of the organization.

Teams make designs daily that affect the direction of the sprint and project. The faster these decisions are made the higher the team’s velocity or productivity. Having a solid understanding of the real goals of the project helps the team make decisions more effectively. Organizations need to learn how share knowledge that today is generally compartmentalized between developers, testers or analysts.

The process of learning and unlearning occurs on a continuum as teams push toward a type of collective self-actualization. As the team moves toward its full potential, the organization’s need to control planning and decisions falls away. If the organization doesn’t back away from the tenants of command and control and move towards the Agile principles, the ability of any team to continue to grow will be constrained because the organizations leadership owns the definition of career success. The tipping point generally occurs when an organization realizes that self-managing and self-organizing teams deliver superior value and higher customer satisfaction (and that in the long run is what keeps CIOs employed).