Chapter 4. Real Teams

Without great people in our organizations, we will never be able to build great products.

Leadership must focus on creating an environment where teams can thrive and focus on excellence with few restrictions placed on their creativity as they seek to build the most innovative products. This approach will result in the greatest degree of customer delight.

How do we enable teams most effectively? How can we break the habits of command-and-control leadership? What is most important to the teams and individuals?

This chapter explores how we can help mature the larger complex adaptive system of organization by maturing the smaller systems upon which it is built—the teams.

When the Agile Manifesto Principle states “The best architectures, requirements, and designs emerge [emphasis mine] from self-organizing teams,” it is summarizing the fact that people who are closest to the work should be the ones making the critical decisions about the work, and that those decisions happen “just in time,” or as they need to happen. We aren’t trying to solve all of the problems up front before we get started on creating the product. If we waited until we had the perfect plan, then we would never be able to get started on actually creating the product.

We really want enough of a vision or an idea about the product to get started working on it, and then we will rely on the expertise of those on the Scrum Team to make the important decisions based on the data they have at any given moment along the way. This is what we call Empirical Process Control; we form a small plan, take some action toward executing the plan, gather data and reflect on how we executed versus our plan, and then reflect on how we are working as a whole and any improvements we should make.

These steps are best illustrated by the Deming Wheel (Figure 4-1), which describes phases of planning, doing, checking, and acting (to improve). The cycles are a big part of what Scrum is all about: Sprint Planning (plan), Sprint (do), Sprint Review (check), and Sprint Retrospective (act). By following this progression, we raise transparency, which allows our teams to reflect on what has been revealed and discovered and then adapt or change accordingly.

This approach is part of what allows us to respond to change more effectively using Agile practices versus traditional practices. In a traditional project delivery model, we would try to analytically derive a comprehensive plan that has every possible contingency built in so that we could mitigate all risks and possible risks along the way. However, history shows that many, if not most, of the risks that we worry about seldom or never happen. The net effect is that we spend a lot of time needlessly planning. Instead, it’s more effective to deal with risk and issues as they arise.

From a management perspective, enabling self-organization to happen is chiefly a function of trust. Trust is like a savings account at a bank. In order to open the account, we need an initial deposit. Likewise, when an organization decides to “go Agile,” management needs to make the investment in their Scrum Teams by granting them an initial deposit of trust. It doesn’t really matter what happened previously when the organization was still following traditional product delivery methodologies. With Agile, we have a whole new set of rules and understanding. The best guideline that can be followed is this: trust the team until there is a compelling reason to NOT trust the team.

As the Scrum Team delivers working software and customer delight increases, then the balance in the savings account will grow. If the team fails to meet its commitments or continually produces features that don’t meet the Definition of Done and/or that fail to delight the customer, then there will be debits to the savings account of trust.

More often than not, the team will delight the customer and will be worthy of additional trust and autonomy over time. Initially, they need to be given the chance to prove themselves, however. This is the most important ingredient in the secret sauce for self-organization: trust.

In almost every team that I have worked with, I have found that the team members are really intrinsically motivated, as Daniel Pink describes in his book Drive. They want autonomy. They are striving to develop mastery in their skills and career path. They are looking for a bigger sense of purpose from their work than just showing up every day for 40 to 50 years and then retiring. People who work with their brains (aka knowledge workers) want to feel like they are making a difference in the world.

In light of this reality, based on 50+ years of research, management can no longer use the same tactics that worked in the factories of the Industrial Revolution, such as Theory X management style, and expect innovative solutions to evolve.

If I am someone who has been writing banking software for the last five years, then I have a pretty good idea about how these types of systems work, the business model, etc. It’s not necessary to tell me every step of the way what I need to do next. Furthermore, if I see that my colleagues are punished or berated every time they come up with a new idea or try something different as a means of exploration and discovery, then I am not going to take any risks or chances by making any suggestions myself. In fact, the first time I make what I think is a legitimate, feasible suggestion and I am negatively reinforced for that, I won’t ever make another suggestion again.

Instead, management needs to work together closely with the Product Owner to provide a vision of what problem they are trying to solve and then stand back far enough so that those who are adept and skilled at problem solving can have room to collaborate using their knowledge and understanding and trying out little experiments to learn more about what works and what does not.

At the same time the Scrum Team needs to have the courage to speak up about its discoveries and be open to possibilities. They need to step away from convention and consider new and alternative ways of working and solutions that may not have been tried before. We can’t just assume that because we have started with x as the first step for the last 75 years of creating products that we should ALWAYS start with x. Times have changed and so, too, must our ways of working.

The ScrumMaster must be there as a situational leader. I often use the analogy of a parent and mention that the ScrumMaster should not be a “helicopter parent” to the team. “Helicopter parents” are those people you see at the playground who are never more than one to two feet away from their children at all times. They insulate them and act as a barrier so that the child never experiences any harm or danger.

In contrast, you see people like my wife and me sitting on a bench at the side of the playground. If one of our children falls from a short distance, it’s a lesson learned in gravity. The child stores away that memory for next time: “Don’t do [this] because [that] will happen.” If we are constantly there to shield them from consequences, then they are not learning those crucial lessons of life. Of course, we don’t think the child needs to experience what a car feels like traveling at 35 to 40 mph; nor do they need to feel what scalding hot water feels like.

By the same token, as the ScrumMaster acts as a coach for the entire Scrum Team, they might allow that team to make some mistakes that are not catastrophic or severe. They won’t let the team do something that would cost the company millions and millions of dollars if they see that risk as being imminent. Nor would they allow the team to do something that would cause significant risk or threat to the general health and welfare of others.

Mistakes are how we as human beings learn, and the more we can learn, the less we make mistakes in the future. They often say that the point of Agile is to “fail fast,” which means that teams are going to make mistakes; it’s inevitable. So, it’s better to make smaller mistakes earlier on and learn from those rather than large, expensive mistakes later on. I don’t like the term “fail,” however, as it injects an air of judgment into the actions of others. There shouldn’t be an attitude of “success” or “failure”—simply lessons to be learned: this works, this doesn’t, etc. As Einstein said, “Doing the same things over and over and expecting different results is the definition of insanity.” That to me constitutes “failure”: doing the same thing over and over again and expecting something different.

For self-organization to occur, teams need freedom, and freedom comes from trust. The ScrumMaster is there to coach, guide, and act as an advisor but not to be prescriptive, commanding, controlling, etc. The best way to ensure self-organization will happen, then, is to stop providing TOO many of the details and allow the team to sort things out on their own. Give them the freedom to explore, learn, and be innovative.

I give each table’s team a stack of small, laminated cards that have various responsibilities on them. Some of these are:

Identify Stakeholders

Protect Team

Create Product Vision

Evaluate Results

Manage Business Risk

Define Sprint Goal

Coach Team

Refine Product Backlog

Manage Vendor Contracts

On the wall near each table’s team, I put three large stickies with the labels Product Owner, Development Team, and ScrumMaster. I also provide tape or drafting dots. The instructions are simple:

As a team, discuss where each of these of these responsibilities should be placed on the wall and tape them there using the drafting dots.

And then I let the teams work on that. It usually takes about 10 minutes.

The net result is that some of the responsibilities are clearly targeted for each of the roles. Some of the responsibilities are shared. There is one in there for fun just to see what the team will do with it: Yell and Panic.

When I debrief the exercise, I talk about the Product Owner first. I read through the responsibilities that the team has mapped to that role and then ask them: From your experience outside of Agile/Scrum, who does this sound like to you?” Inevitably, they say “the project manager.”

They come to this conclusion on their own and it’s a HUGE “A-ha” moment. Most organizations tend to automatically put their existing project managers into the role of ScrumMaster. That can sometimes work very well. I myself was a very structured, regimented project manager in the PMI PMP sense of the role. I was able to make the necessary mind shift to understand the value proposition of Agile and how the values, principles, and practices relate to and work with an organization’s culture to deliver the benefits of Agile.

However, many PMs just aren’t ready or willing to make that mind-set shift. They just can’t overcome their tendency and inclination to micromanage, command and control, and fall back on metrics to determine health rather than letting the product speak for itself. In some cases, I have been able to help coach people through this and they have become great ScrumMasters. In other cases, I have failed to help people make the transition.

At this point in the discussion, I take the opportunity to point out the difference between a project and a product. A project is a very specific instrument for funding the execution of work. A product is the outcome of the work. A project lifecycle is relatively short when compared to the lifecycle of the entire product. By traditional standards, a project is typically 1 month to 1 year in duration, with some exceptions. A product lifecycle could be a couple of years to 20+ years in some cases.

It is the Product Owner’s responsibility to ensure that the product receives appropriate funding so that the work can be executed and thus, value delivered to the customer. Scrum does not dictate HOW to fund the product, however. Thinking about some of the other dynamics of Scrum, funding is somewhat simplified in the sense that we are dealing with fixed costs, which are also considered “sunk costs” in traditional finance terms.

We have a Development Team of five to nine people, which Scrum tells us should be full-time, dedicated to ONE Scrum Team. For ease of calculation and illustration, let’s assume a blended rate of $100K/person for an engineering role. This means that any given Development Team that is following what Scrum says is going to cost the organization $500 to 900K/year regardless of what they are working on.

Furthermore, in Scrum, we have FIXED time boxes or iterations we call Sprints, which are one to four weeks in duration. We can say that a Development Team costs the organization $9,600 to 17,300/Sprint with one-week Sprints; $19,200 to 34,600/Sprint for two-week Sprints, and so on. Very predictable.

Now, let’s assume that we are using two-week Sprints and want to have a formal, standardized release cycle of once every six Sprints; that is, we are pushing out to production every 12 weeks. We now know that each release costs our organization between $115 and 208K. That is what we call: FIXED PRICE, FIXED DATE.

What is NOT fixed? The scope. However, that’s one of the key ingredients to the whole value proposition of Agile: we are able to select the scope along the way. Every two weeks (using our example) I can change my mind about things in order to make the customer happy. Also, I am going to get confirmation every two weeks that what the Development Team is doing is valuable to the customer; that is, that they are on the right track and the product is meeting expectations.

There are really no other complex metrics necessary to track progress for products or projects beyond what has been mentioned, then. Each Sprint, we know how much has been spent. Each Sprint, we know how much is being delivered. If we want more granular figures, we choose a shorter Sprint duration. Perhaps we could introduce something like the Happiness Metric or Net Promoter Score to capture actual customer delight. Anything more complex is prone to issues and bias.

With this understanding of how the Product Owner/PM are related in responsibilities, we now turn our sights on the ScrumMaster to see how they fit in to the equation.

The three roles in Scrum act as checks and balances to one another (Figure 4-2).

The ScrumMaster is an equal role to the Development Team and to the Product Owner. They are not in charge of either. They don’t manage either. They are absolutely necessary as a separate but equal branch of “Scrum Government.” I mention this because checks and balances won’t work if one entity is fulfilling dual roles. It would be like the President of the United States acting as Speaker of the House or the Chief Justice of the Supreme Court. It just cannot be. The ScrumMaster needs to be a dedicated, independent individual.

Asking about “driving process” has connotations of forcing, prescribing, commanding, controlling. A better question might be: How does a ScrumMaster help the Product Owner become a high-performing member of the Scrum Team?

As with the Development Team, the ScrumMaster should be coaching the Product Owner as well. The ScrumMaster is responsible for removing the product owner’s impediments, just the same as they would for the Development Team. In order to be an effective coach to the Product Owner, the ScrumMaster needs to have a full understanding of what the Product Owner’s role is within the Scrum Team. I often advise those who want to truly excel at being a ScrumMaster to take the Certified Scrum Product Owner course so that they have a full understanding of how to split PBIs, what makes a great product vision statement, and other Product Owner responsibilities so that they can advise the Product Owner effectively.

Overall, the ScrumMaster needs to be someone who enjoys working with people. A completely introverted and reclusive person who can’t stand dealing with people is not going to do a very effective job as ScrumMaster because they will be constantly acting contrary to their own nature.

Someone who is adept at working with others and has an understanding of politics, that is, of looking at the “art of the possible,” is someone who will do well as a ScrumMaster. They have no real power as ScrumMaster because Scrum does not sanction power for the ScrumMaster. Instead, their “power” comes from the influence they build via relationship capital and interactions. The ideal ScrumMaster is respected and revered throughout the organization regardless of their background, experience, official title, etc. They are not someone who runs around violently waving burndown charts and impediment logs at people.

Instead, because they are influential people, ScrumMasters are able to help people understand why they should be supportive of Scrum; they can answer the “What’s in it for me??” question that everyone has on their mind. In answering this question and helping people understand the value of Agile and Scrum, they will inevitably be evangelizing and garnering support for the effort. This is as close as they should get to “driving” the process.

If we asked our parents a question that could have been answered by looking it up somewhere, we would get a question back: “Did you look it up?”

I quickly learned that the way to get answers is to be self-reliant and not LAZY. Do some diligence before you ask something that might be well documented or well known.

After a while, I would come to my parents and say, “I was reading up on curare in the Funk and Wagnall Encyclopedia and how certain tree frogs in South America secrete that chemical as a defense mechanism. They are also brightly colored so as to warn predators to stay away. However, I don’t quite understand how curare works. Can you help me understand it?

My parents would be happy to answer, if they knew the answer themselves, because they could see that I wasn’t just being lazy at that point; I needed guidance and additional information. If they didn’t know the answer, we would go to the library so I could research more, and they would help also.

Also, I might say “I wanted to look [this] up in the encyclopedia but I wasn’t sure where to start. Can you give me a hint and then I can go look for myself?” They were happy to give me clues in that case also.

Today, we have Google, Bing, Wikipedia, and thousands of other sources all within seconds’ reach from our fingertips. Oftentimes, I am asked questions about something that I know could have been resolved in 3 seconds by searching one of these sources, or possibly 10 to 15 seconds by looking on a particular Web site and digging around.

For instance, I am happy to answer questions about things that aren’t clear from reading something that is online. Let’s say you want to become a Certified Scrum Professional. The best place to start is the Scrum Alliance Web site (see Figure 4-3), right? That’s who curates and shepherds that certification. So, logically, the most recent and important information should be on their Web site ... somewhere ... (probably under “Certifications”).

In my CSM and CSPO courses, I spend about 30 minutes or so running down the entire certification stack with Scrum Alliance (SA) so that people get clues about where to go next for information and guidance. I am really encouraged when someone comes to me with a question like “I read all the requirements, downloaded the application, filled it in, etc. I have the requisite experience and SEUs, but I just wanted to get your thoughts and feedback before I submit. Do you have a few minutes to take a look?”

ABSOLUTELY!

I am more than happy to help people who help themselves.

What kinda bugs me a little is when someone says, “What are the requirements for CST? I want to be a trainer,” right after they finish my CSM class. First, we covered that briefly in class. Second, you know that CST is an SA certification, so, why not start there by researching it a bit? Finally, I created a site with information about all of this so that I can refer people there since I am asked these same questions over and over: http://www.agiletrainer.org

Honestly, I am not trying to be mean here.

It’s more like my Mr. Miyagi approach to coaching/training people. If you want to be a CEC or CST (or CTC), which are considered to be lead/guide level in terms of career levels for Agile, then you need to first learn how to lead/guide yourself. If you can’t figure things out for yourself, then how can you help others?

So, essentially, when someone asks me about something that I think is obvious, I might say “Daniel-san, Google ‘CSP.’” or “Daniel-san, show me ‘search SA site for CST.’”—not to be rude or disrespectful, but out of love and a desire to help someone grow by becoming more self-sufficient. If I don’t, then when I am gone or no others are available to give them the answers, they will be lost ...

First, “Development Team” is probably a poor title/description for the actual role that that team plays in product development. In reality, the Development Team includes any and all skillsets necessary to iteratively and incrementally build the product. Scrum emphasizes that each Sprint MUST produce a shippable product increment, which represents value delivery to the customer; that is, early and continuous value delivery throughout the product lifecycle. In order for Development Teams to meet this requirement, each team MUST have ALL of the skillsets represented within its team members. This includes skills such as analysis, design, coding, testing, deployment, marketing, documentation, support, etc.

If a particular product includes a database, then Scrum says SOMEONE on the Development Team MUST HAVE database knowledge and skills. If the increment has a graphical user interface, then Scrum says SOMEONE on the Development Team MUST HAVE design skills and SOMEONE on the team MUST be able to do user acceptance testing (UAT). And so on.

In order for “shippable” features to come out of each Sprint, they must meet the Definition of Done that the Scrum Team has agreed upon for the product. This means the feature is fully developed, fully tested, fully ready to go. Scrum does not talk about where the people who have the title of “quality assurance” should live within the organization. What it talks about is having assurance that there is quality in the increment that is produced during each Sprint.

An organization can still have traditional roles like developer, tester, quality assurance, business analysis, documentation specialist, etc. They would be part of the Development Team and would be ultimately responsible for ensuring that the product increment is shippable by ensuring it meets the Definition of Done for each sprint.

There are some aspects of development that are not explicitly mentioned in Scrum but are inherently true. For instance, if the goal is to have a shippable product increment EVERY Sprint, then the entire product needs to be completely regression tested EVERY Sprint. Doing this manually every Sprint will not really be possible because the code base will continue to grow throughout the product lifecycle and will eventually get to the point where the regression testing required takes longer than the Sprint duration.

Thus, it is inevitable that the Development Team will be required to automate their testing efforts. Again, Scrum does not specifically say this, but if we do the math, there is no way to get around it. This means that the notion of having people who only code or only test or only do manual testing, etc., is pretty much dead. In order for organizations to be competitive in their product development and for workers to be competitive in their skills and marketability, there will be an increasing need for people themselves to be cross-functional, not just teams as a whole.

Several of the companies that I have coached eventually decided to move away from having strict titles and role delineations and instead, hired only “engineers,” not “software developers,” “quality assurance,” etc. Most importantly, Development Team members should have an entrepreneurial attitude when it comes to product development work. For instance, if a testing task is next and I have time, it doesn’t matter if my background is mostly coding or mostly DBA or whatever; if I CAN do the task, then I should do the task since that is what is most needed by the team that I am part of at that particular moment. I don’t say, “Well, I am a developer and testing isn’t MY job.” That is a piss-poor attitude, not entrepreneurial spirit. Coding is everyone’s job. Testing is everyone’s job. Documentation is everyone’s job. Delivering value to customers is everyone’s job. This is a core concept to not only Scrum, but Agile in general.

If your organization is set on having a specific role dedicated to quality assurance, that may be just fine. However, those individuals MUST be dedicated members of Scrum Teams for the products that they are testing. If they are a shared skillset, there will be nothing but issues as they experience conflicting priorities and performance problems as they continually encounter context switching.

Scrum itself doesn’t prescribe ALL the things that the ScrumMaster should be doing throughout the Sprint. This is a big part of why Scrum is a lightweight framework and not a methodology. It describes the relationship that exists between the three roles and mentions some of the activities that the ScrumMaster engages in: facilitator, coach, impediment remover, intermediary, counselor, teacher, etc.

Michael James wrote a fantastic set of guidelines entitled “A Sample Checklist For ScrumMasters” in which he lists many different suggested activities that the ScrumMaster could be working on to make the Scrum Team a high-performing unit. In some cases, it might make sense for the ScrumMaster to be helping to coach the Development Team in terms of technical expertise. They might be coaching the Product Owner in terms of writing user stories. With all of these different “hats” that a ScrumMaster must wear, there are many different skills and character traits that highly effective ScrumMasters have.

ScrumMasters are lifelong learners. One of the first things I tell people in my ScrumMaster class is that the course is only the BEGINNING of their journey as a ScrumMaster. In fact, a lot of what I talk about in my class includes external sources that the students should be following up on in order to broaden and deepen their understanding of ScrumMaster mastery. I mention one to two concepts from many different sources as sort of a tasting menu of skills. There usually isn’t enough time in a two-day CSM class to go as deep as I would like on any one skill or resource.

A good ScrumMaster will look for and see the possibilities and opportunities. A great ScrumMaster will look for conventional ways of doing things, but won’t be tied down to ONLY following convention. If there are options that have not been tried and it seems like those might provide a solution to a problem, the ScrumMaster will run the experiment with the purpose of learning and trying something new. Failures only happen when we continually make the same mistakes over and over without trying something different. We don’t try different things because we are afraid of breaking with tradition and convention; or worse, we are working in a culture and environment that punishes deviation from the norm. So, we continue to fail.

A great ScrumMaster has influence with others but not necessarily any real power or authority—at least not due to the fact that they are in the role of ScrumMaster. Highly effective ScrumMasters understand interpersonal dynamics and how to relate to others—not in a superficial or manipulative way but in a genuinely caring and meaningful way. They also understand politics and how to negotiate mutually beneficial solutions. It was Otto Von Bismarck who said, “Politics is the art of the possible.” This means that being successful with organizational politics means being able to negotiate solutions with others effectively, which is certainly within the realm of what the ScrumMaster must do.

Although it is not absolutely necessary that the ScrumMaster be technical, having a technical background can be very useful. With a technical background, a ScrumMaster can also coach the team on Agile engineering practices as well as other practices. When impediments arise, the technical ScrumMaster won’t require a lengthy description of the problem, and there is less risk that they will misunderstand what is needed to remove the impediment. A ScrumMaster with a technical background can help bring more junior people up to speed with coaching and mentoring.

A model ScrumMaster will also have a servant’s heart; their sole interest is in serving the team and ensuring they have everything they need to be successful. They clear the path for the team and help motivate the team without using harmful command-and-control tactics. They wake up every morning and ask themselves: “How can I help my team be more successful today??” They aren’t in this for the glory or the status; they like helping others.

ScrumMasters practice Situational Leadership. Based upon the circumstances and the competency level of the Scrum Team, the ScrumMaster will provide guidance with different approaches. For instance, if the Development Team has overcommitted in one of their Sprints, the ScrumMaster wouldn’t necessarily jump in and correct them. He or she might wait until the end of the Sprint to allow the Development Team to realize their mistake and to make the observation themselves, along with action items for preventing future overcommitments. If they continue on with overcommitment, then the ScrumMaster may move to more of a coaching approach by practicing the Socratic method. If the team continues to overcommit, then the ScrumMaster would move to a more direct approach to curtail the overcommitment once and for all.

Finally, the vital ingredients to ensuring success as a ScrumMaster are mostly concerned with character and personality traits. It will be difficult for someone who can’t stand talking to people to be a ScrumMaster because a large part of the ScrumMaster’s role is focused on dealing with people. They must be patient, deferential, trusting, and unbiased, among many other traits.

This line of thinking reflects a poor understanding of what we really stand for as trainers and coaches. There is a gross misunderstanding of what the CSC represents for sure, which is why, historically, there has been a pass rate of about 15 to 18 percent. Most of what we embrace, practice, and look for in CSC candidates are actually practices and foundation in supporting disciplines that are well beyond just Scrum.

Rather than being a hammer looking for a nail, Scrum represents something like a multitool; its practices can be used for MOST situations to accomplish great things, but sometimes, we need other tools also. Thus, Kanban is another set of practices that I recommend when a situation warrants its use.

For instance, it doesn’t make much sense for me as an individual to attempt to practice Scrum for managing my own business. So, I use Personal Kanban to track pipelines, classes, course refinements, coaching engagements, travel, community events, etc. My wife uses Kanban to help the kids self-organize around their chores, homeschool topics, music lessons, swim events, etc.

And I often recommend to organizations who are adopting Agile practices (like Scrum) that they use Kanban to stop the hemorrhaging of support tickets due to crappy code having been deployed to production. This sometimes results from a lack of engineering rigor/discipline, but more often than not, it is a byproduct of extortion and coercion from the business to get things out there quicker. This narrow-minded approach fails to see that the cost of fixing a defect is exponentially higher the later the defect is addressed, with the worst case being in production.

So, even the most well-intentioned and penitent organization is going to have legacy systems out there with serious and even critical issues. Rather than have these bog down the Development Team in Scrum with disruptions during a Sprint, it’s oftentimes better to have a dedicated team that is following practices that are more interrupt and flow driven, like Kanban.

With Kanban, a support team can collect support requests in its input queue and work on these in a first in, first out (FIFO) fashion (or whatever other priority method it wants), following the work-in-progress (WIP) limits in their workflow until some super high-priority item is logged, which would qualify for the expedite queue. That item would then be allowed to violate the WIP limits on the workflow states, and the team would swarm on that until it was done. Then, it’s back to following the WIP limits and processing work as normal.

While the support team is working on these “trouble tickets,” another team would be free to plan more effectively and to follow more of a longer-term vision for the product than just “fixing stuff,” which can be unpredictable and chaotic at times.

Some people argue that Kanban can also be used for new product development as well. I agree, with the caveat that there is a degree of risk that the end product would not be a cohesive product from end to end due to a lack of vision and longer-range planning. This is not to say that you can’t do longer-range planning and visioning in Kanban. These practices are simply not an inherent part of Kanban. Thus, Kanban tends to be reactive in nature as teams use it for addressing highly unpredictable and volatile work streams.

A way to mitigate this risk somewhat is to have an Input Queue, which is a “free-for-all,” and then a workflow state marked “ready,” which is the refined state from which the team pulls items to work on. This would require some kind of role like the Product Owner in Scrum who is shepherding and refining the items from input queue to ready following the business value ranking approach of traditional Scrum product backlogs.

We followed this approach at the U.S. Treasury Department with a great deal of success. In addition, we added other Scrum practices such as the Daily Scrum to talk about what had been accomplished since the last meeting, what would be accomplished before the next meeting, and if there were any impediments. The features were added and prioritized by the Product Owners and then there were feedback loops every two weeks on the product (Sprint Review) and the team (Sprint Retrospective).

There was the notion of a shippable product increment, which continued to grow with each feature such that it was always ready to be deployed if the decision was made. That is, there was no need to wait until the end of a Sprint to get the latest features because they were being added to the SPI via continuous deployment. With continuous deployment features are created (often with Test-Driven Development [TDD] or in our case, Acceptance Test-Driven Development [ATDD]) and automatically integrated with scripts. The code is then automatically integration-tested with additional scripts. Because the Acceptance Test was driving the automated tests, and thus, the development effort, there was a reduced need for a formal UAT cycle, with some representative of the business doing more of a usability evaluation than a reverification of what had already been tested as they had been in the past.

There was no formal Sprint goal as there is in Scrum. Rather, the items in the ready state were ordered in such a way that there was a cohesive purpose rather than just a random grouping of unrelated features.

The results were amazing. The business was pleased. I eventually left the engagement because they didn’t need my coaching anymore. They were truly self-managing and self-organizing with some sharp coaches who were on the teams left behind to help guide and mentor the team.

A carefully selected blend of practices can be used in the case of Kanban, Scrum, and even eXtreme Programming. The key is to ensure that there are feedback loops of some kind to ensure that there is continuous attention to customer delight via the product and technical excellence, interpersonal growth, and overall mastery among the teams. It is because these mechanisms for learning are ingrained in the practices of Scrum that many of us are so fond of Scrum specifically, but not to the complete ignorance of other practices.

THANKSgiving, Black Friday, Cyber Monday, GIVING Tuesday ...

The marketing departments of most organizations are in high gear capitalizing on the #FOMO tendencies of consumers.

The Christmas season draws people to the stores, malls, roads, etc., even though many of these stores have had Christmas-oriented stuff since before Halloween. What is interesting is that when you talk to people, they all complain about it and are full of dread at having to face the crowds.

Most of the shopping for my wife and I is done online these days—not just for big-ticket items like electronics and such, but even some perishables on subscription so that they are delivered monthly and at a greatly reduced cost. We really hate leaving the house most of the time to do shopping.

Yet, even we, who are somewhat socially challenged, find ourselves gravitating toward the mall, Costco, etc., out into the fray ...

It seems to be a downward spiral too.

When I leave the house in the morning to do errands, I am in a great mood but a little worried about the crowds. By the time I return to the house in the mid-afternoon, I am just completely livid. If I continue on with filling my day with activities and trying to get 18 hours of stuff done in 10, then it just gets worse.

It’s this anxiety that I think is driving the horrible moods of ALL those who go out into the world during this season; they worry about accomplishing the massive list of things they have to do and know that there is heavier traffic and people acting selfishly, etc., and then it all becomes a self-fulfilling prophecy.

My list of stuff I need to do is always massive. However, lately, I have been treating it more like a product backlog; I make a list of ALL the things I would like to do and then pick two to three things that I will commit to getting DONE for certain. That’s sort of like my Sprint backlog.

Historically, I have also been guilty of having the Clark W. Griswold ideal of what DONE means. They say that “Perfect is the enemy of good.” So, rather than striving for absolute perfection in everything, which is impossible anyway, I am considering what is necessary in terms of acceptance criteria and other Definition of Done items for the things I need to do. What is my MVP (minimum viable product) for the things I need to accomplish?

When I have reached that state, I reflect on it, think, “This is good enough. Moving on.”

And so maybe the answer for most people is to acknowledge the MASSIVE list of things they need to do but really just focus on doing a handful at a time well or to an acceptable level before moving on to the next handful of things?

“If you have food in your refrigerator, you are more fortunate than 75 percent of the world who have no food or clean water ...” and so on, culminating in the statement: “If you can read this, you are more fortunate than 3 billion people in the world who can’t read.”

I am always skeptical of the actual numbers and origin of these things but the crux of the message is sound: there is very little that most of us in this country have to worry about.

This is another acknowledgement we need to make ...

Most of us have not only a place to live, food, heat, etc., but all of these things in abundance. In addition, we have multiple electronic devices, multiple cars; our children have multiple electronic devices; they are involved in sports, music, and other activities, and so on.

Why is it that we get upset when we can’t find a parking space that is less than 200 feet from the entrance to the store?

Why do we tailgate and not let people merge when driving around the town or on the freeway?

I am willing to admit that I get into that mode a lot of times. There is a friend of mine who, when I first met him, I thought, “What a conceited jerk.” But over the years, I have gotten to know him and, in fact, when I saw him at the Scrum Gathering in Phoenix, he shared with me that he has figured out how to classify himself: “I am a well-intentioned asshole. I really, really try to do the right things but I end up botching it and coming across wrong.”

Wow. That pretty much describes me too. I really try, but I end up like Tommy Boy trying to nurture and close a sale ...

Lately, I have just been trying to pause more. Be present. Reflect on life in the moment and express gratitude for my basic needs being met at that very moment. It’s working. I am starting to feel better. People are noticing that I seem happier.

If you have everything you need (and more), then I believe you have a responsibility to be joyful, happy, thankful, etc. Taking a moment to reflect on our lives and assess what we truly have to be worried about, there isn’t really much. (Especially if you are reading this, since that means you can read, have a computer, etc.)

A friend of mine was telling me the story about a friend who lives in another country in a house that is half the size of an average American home ... with their parents and in-laws. They commute 2.5 hours one way to work and 2.5 hours back from work every day so that they can support all of these folks. AND, my friend was telling me how happy and joyful this person was with life in general.

And so, I think that we have a responsibility to be joyful, to be an inspiration to others. Make the conscientious decision to focus on the positive. Choose to be happy!!

I don’t subscribe to the New Age philosophy that talks about things like believing in x will make x happen. Living in Delaware, I have never opened my mailbox to find two Double-Doubles and a vanilla shake from In-N-Out waiting for me ...

I do believe that if we focus on negative, we will see negative. If we look for positive, we will see positive. This is why we should regularly pause to reflect on our lives, express gratitude, and make a decision to be content and even happy. In fact, I find it to be somewhat contagious. When I have chosen to not let petty things bother me and openly make an effort to look on the bright side, I find that others around me do the same.

In general, if you want the world to be more kind, loving, and understanding, then be more kind, loving, and understanding ... and happy.

Peace and blessings.

P.S. I accept (and give) hugs freely!!

Also, it’s ok to say “Merry Christmas!!” to me.

What’s most important to me regarding this question is the notion that someone can fulfill both roles simultaneously, that is, play the role of ScrumMaster while they are on the Development Team. For multiple reasons, it is not possible for a ScrumMaster to be effective if they are also on the Development Team. The primary reason has to do with the government system of the United States.

First, let’s talk about Economics 101. The primary rule of economics is unlimited wants, limited resources. What this means for software product development is that the customer or their representative (aka “THE business”) basically wants EVERYTHING because they don’t know exactly what they want. Conversely, because IT is composed chiefly of cynical, moody people, NOTHING is ever possible. I am kidding, of course. Well, kind of ...

Ultimately, we have a dilemma with a frequent stalemate between “THE business” and IT. (One of my pet peeves is calling the nontechnical people “THE business.” The whole organization is “THE business,” and we are all here to run it like a business, not a hobby. So, let’s get that straight.) The arguments frequently become unproductive and argumentative. There is always an opportunity for this condition whenever we have a system with two entities.

Now, let’s think about the government of the United States. There are three separate but equal branches of the government that represent separate but equal distribution of powers: executive, legislative, and judicial. The roles of these branches are (respectively) the President of the United States, Congress (House of Representatives and Senate), and the Supreme Court of the United States. No one is allowed to hold office in more than one branch at a time because this would represent a conflict of interest. The system was specifically designed this way and would fall apart if exceptions were made; it would cease to be separate, equal, balanced.

This is the same situation we have with the roles of the Scrum Team and why the ScrumMaster can’t also be on the Development Team simultaneously; the system would fall apart because there would be a conflict of interest. Actually, there are several conflicts of interest with the ScrumMaster also being on the Development Team.

The most obvious should be that the ScrumMaster is a full-time role. As Michael James points out in his highly acclaimed “Sample Checklist for ScrumMasters,” a ScrumMaster who is effectively coaching the Scrum Team on all of those various things won’t have time to effectively coach another team (or more). If an expectation is placed on the ScrumMaster to do other things than coach one Scrum Team, they won’t be able to devote 100 percent of their time into making that one Scrum Team 100 percent effective.

All professional sports teams in the world have players who are the best of the best at whatever sport they are playing. They don’t need to be told the rules of the game or how the game is played. However, all professional sports teams have dedicated coaches. This is because the players can’t coach themselves while they are busy playing the game. It requires someone who is outside the game, observing the bigger picture of the game and not having any direct responsibilities IN the game.

Furthermore, when someone is first learning a sport like golf, for instance, there will be a huge difference in improvement from the time they are, say, age 12 to age 14. However, once they have been playing for 30 years, there won’t be that much obvious progress between the time they are 42 and 44. The improvements will be much more subtle and nuanced.

The other reason we don’t want people playing dual roles is that it is actually a sure-fire way of letting the team down. If the ScrumMaster/dev team member has impediments to remove (their primary role as a ScrumMaster) then they won’t be able to focus on their own deliverables for the Sprint. This is letting the team down by not contributing and getting their work done. However, if they focus on their own work to the neglect of the impediments, then again, they are letting the team down by not removing those impediments. Either way, the team loses.

SO, no, a Development Team member CANNOT be an effective ScrumMaster if they are being expected to fulfill both roles simultaneously.

1: the quality or state of being self-governing; especially : the right of self-government

2: self-directing freedom and especially moral independence

3: a self-governing state

“Management” is presumably in control of the organization to begin with when they first decide to pursue becoming more Agile in their thinking. This means that management must first acknowledge that they are giving up some of their right to manage or govern the teams and that those teams will gain more “self-directing freedom” of some kind. The nature of the freedom and the consequences are what need to be explored and defined.

Freedom comes at a price.

As Franklin D. Roosevelt mentioned in his Undelivered Address for Jefferson Day (April 13, 1945):

“... great power involves great responsibility.”

As management gives up power and that power is transferred to the team, so is the responsibility that accompanies it. The team can make much better decisions about the day-to-day work than management because the team is more intimately involved in the work itself. They see the more granular details and are focused primarily on the small and the immediate, aka, the tactical aspect of execution.

This actually provides freedom to management as well. When management isn’t burdened by looking after the tactical, they can focus more on the strategic-level planning and execution. The same holds true for the Product Owner for the Scrum Team. The Product Owner is at liberty to discuss and flesh out WHAT the customer wants without having to worry too much about HOW it is implemented.

Arguably, autonomy is not really something that is granted by management, but rather a stepping away from or relinquishing of control by management. This often takes the form of providing less prescription, less instruction, and more visionary guidance. There is also an emphasis on trusting the team to do what it says it will do, that is, honoring its commitments.

In the 2013 version of the Scrum Guide, the language around the Development Team making a “commitment” was changed to “forecast,” which arguably maintains the spirit of the intended meaning but has resulted in a MUCH weaker position and greater difficulty in selling the value of Scrum to organizations. In coaching teams, I prefer to emphasize to the team the importance of committing to SOMETHING, even if it is just one feature for an entire Sprint. The reason why is simply trust.

Trust is a bank account. When you first meet someone, you grant them an initial deposit in the bank account of trust. Over time, as that person pleases you by living up to their commitments and so forth, the balance of trust grows. Whenever they fail to meet their commitments, the balance falls. We can get into a condition where there is a zero balance or even a negative balance, which can never be “repaid.”

In many organizations, the balance in the bank account of trust for management and the team is at a dangerously low level before they begin to adopt Agile practices. One of the first things we must do is grant forbearance and reset the accounts to a positive level. Thus, management commits to trusting the team and the team commits to trusting management—until there are reasons not to.

When teams make a commitment to deliver something in a Sprint and they execute on that commitment, it builds trust with management and the business. With additional trust comes the willingness of management to relinquish even more control so that the team can have more autonomy.

Thus, the key to “get true autonomy from management” lies in re-establishing the bonds of trust and repairing any fractured relationships that might exist.

It’s also important to note that true trust and true autonomy involve risk of failure and choice. That is, if you are entrusting a team to perform some task and there is absolutely no risk of failure, then the trust really has no value or association with the team itself, per se, and there is really no autonomy involved. The same is true if there is only one possible choice to be made. The team is essentially a prisoner to a single option, not a free-thinking group that could consider a situation, various options, and a definitive course of action. The latter would represent autonomy.

Ultimately, management is most effective when dealing with vision and strategy and leaving execution to the team.

Even before you take the class or show up for the workshop/conference, prepare yourself mentally by leaving your preconceived notions at the door. Getting the most out of the class begins with having an open mind and thinking about what’s possible. Nothing is more frustrating to a speaker, coach, or trainer than to hear a student say “This is all nice in theory, but I live in the REAL world ...” It’s condescending, patronizing, and basically says, “I know better than you do” even when the speaker, coach, or trainer has many years of experience.

It reminds me of the story of the Zen master who sits down to have tea with his student and he begins to pour tea into the student’s cup. The student takes a drink and the master again fills the cup until it is overflowing. The student frantically cries out that the cup is overflowing and can’t hold any more tea. And the master replies: “Until you empty your cup, I cannot fill it for you.”

Such is the case with students who come to class with too many questions built upon the premise that what they will be learning will be integrated with what they already practice rather than replacing what they already practice. Agile involves a very drastic paradigm shift in thinking from the world of speculation, analysis, and guesswork back to what’s natural, scientific, and empirical.

It is important in learning about Agile practices to understand fully WHY the practice is followed, WHAT the benefits are, and the mind-set behind the practice. Doing so can help immensely when considering what to do first when returning to work.

The next step in implementing what you learn would be to look for the high-impact, low-cost practices that could be implemented immediately.

For example, from a general team perspective, consider having a Daily Scrum for 15 minutes or less in lieu of the weekly status meeting. Create a product backlog that has features or requirements on it ordered in terms of value from highest to lowest. Meet together every couple of weeks to discuss how the team is working together: What is going well? What isn’t going well? What could they try going forward? Get the Business and IT together every couple of weeks to discuss what features will be worked on over the course of those weeks.

In terms of engineering practices, help the Development Team to practice test-driven development (TDD) and pair programming to increase code quality. Automate regression test scripts to reduce time spent on manual regression testing. Conduct regular peer reviews. Discuss and implement continuous integration.

Beyond that, it is important to quickly build an organizational transformation backlog. This will help identify improvements and practices that can be implemented across the whole organization so that progress can be demonstrated and tracked.

Quite often, organizations have no real sense of how they are doing as they go through their adoption of Agile practices. Being hyperfocused on metrics to gauge how things are progressing would not be a productive approach. The emphasis would soon turn toward making the metrics look as good as possible while losing sight of the improvements that were being made.

Instead, tracking what improvements have been suggested, which have been implemented already, the priority of the next items, etc., is useful to help keep things visible and manageable. From looking at our progress on the organizational transformation backlog, we can get a sense of how we are doing without turning to heavyweight metrics.

Goodhart’s law tells us that focusing too much on metrics and using them as a target reduces their effectiveness as a measure. For instance, if we are using the number of defects found to determine bonuses for our QA analysts, we can expect to see the number of defects found to continually rise. This is because the workers are aware that they are being measured with this metric and that it is a target being used to determine their bonus. Whether deliberate or unconsciously, they will be inclined to find more “defects” so that they are eligible for a higher bonus.

Thus, trying to boil it down and quantify how the Agile adoption is going misses the whole spirit of what we are trying to accomplish.

But seriously, the Scrum Team has three roles, remember: ScrumMaster, Product Owner, and Development Team. Because the Development Team has all of the cross-functional skillsets required to produce the product, any need for UX/UI work would be included on the Development Team with the other necessary skillsets.

This would also be the appropriate place for developers, quality assurance, database analysts, architects, DevOps, and any other skillsets that are required to produce a shippable product increment at the end of each Sprint, that is, stuff that meets the Definition of Done.

Definition of Done should cover anything and everything required to ensure that the features being worked on are ready to be put into production as effortlessly as possible by the end of the Sprint, so that if the Product Owner says, “This looks good, I want to ship it,” the features are in production almost before they finish the sentence.

During the second phase of Sprint Planning, when the Development Team is discussing HOW they are going to implement the items on the Sprint backlog that they just committed to, they would also include in the discussion any UX/UI design concerns that would be involved. They would also include a discussion of architecture changes, database changes, and many other elements and concerns they might have for each of the features on the Sprint backlog.

One harmful practice/undesirable behavior (aka “anti-pattern”) that I have seen time and again is to have a pool of “shared resources.” These PEOPLE in that group represent some skillset the company feels is too expensive to hire for EVERY team. Oftentimes, UX/UI falls into this category along with DevOps, DBAs, and others. There are several reasons why this is an anti-pattern.

First, teams such as the Development Team progress through stages of development and maturity that roughly follow the progression laid out by Bruce W. Tuckman (1965) called the Tuckman Model: forming, storming, norming, and performing. Whenever some dynamic of the team changes, the team resets back to forming again and could theoretically never reach the point of being a high-performing team.

For this reason, it is a better practice to find a way of integrating the required skillset into the team—for instance, having someone who is interested in learning the desired skill pair with the individual who is the subject matter expert (SME) in that skill the next time they aid that team. As they work together, the proficiency of the “apprentice” would increase and perhaps they would also be seeking outside instruction, mentoring, reading books, etc. Over time, the apprentice would become the resident expert on the team as a cross-functional Development Team member specializing in their original skills plus the newly acquired skills.

Many times I hear the argument that if someone has multiple skillsets, then they will cease to be an SME in a particular skillset. This is not logical.

If we consider that ALL doctors are MDs, we can agree that they all have about the same fundamental level of training as generalists. Some have indeed decided to continue on in their schooling and specialize in one area of medicine or another, such as upper respiratory, cardiovascular, neurology, etc. Still others have multiple specialties, however. There are doctors who are fantastic heart surgeons but also “specialize” in respiratory medicine. Specialization does not automatically mean exclusivity.

By the same idea, there is no reason that a developer could not become an accomplished DBA. In fact, the skillsets are very interrelated. It’s not like expecting a master stonecutter or carpenter to become a concert master (virtuoso on the violin).

Furthermore, I remind people that in this day and age, there are 10- and 11-year-old kids who are creating apps for the iPhone and building games and such with World of Warcraft. In a handful of years, this generation will be flooding the market with coding skills. In general, the job market is becoming increasingly more competitive so that people MUST find ways to differentiate themselves and demonstrate their value in multiple ways. Anyone who is not expanding their knowledge or continually growing in their learning and abilities is committing career suicide.

The second reason that it is a harmful practice to have a pool of shared skillsets is that there will be times when the demand outweighs the number of available SMEs. This is especially dangerous and frustrating in the case where an SME is simultaneously serving the needs of two or more teams. They are put in a position of having to manage expectations and demands presented by politics rather than focusing on practicing their craft and doing it well.

It does make sense to have a community of practice that would represent the UX/UI community and provide a place where ideas could be cross-pollinated and even standards set, if necessary. This way, there would be consistency across all applications that the organization develops.

In conclusion, the answer to this question follows the tire store model. When you walk in to buy tires, there are usually stacks of various tires representing different quality and performance characteristics with a sign on each that reads “Good,” “Better,” and “Best.” The “good” practice is to have some full-time SME help in a particular area and to have the same people work together regularly with the same teams so that they can establish SOME rapport with the team. The “better” practice would be to have the SME join the team they are serving for an entire Sprint and to help cross-train and mentor someone on the team to be more capable with that skillset. The “best” practice would be to have someone dedicated on the team that needs that skillset, either as the full-time SME or as a cross-functional member who can provide other skills to the team as well.

By this point, the person becomes agitated or flustered because I have caught them in an exaggeration and they realize it.

Scrum prescribes a set number of meetings (see Figure 4-4), and each of these serves a specific purpose. So, skipping any of the meetings would break the system and the results would not be consistent with what was intended by the founders of Scrum.

Furthermore, for all the meetings except the Daily Scrum, Scrum says that the duration should be proportional to the duration of the Sprint; it even provides formulae for each meeting as a guideline.

Usually what I find is that people are REALLY concerned over the amount of time spent in meetings, not really the number of meetings. However, this is a result of going WAY over what the guidelines are for time.

Let’s take a brief look at the various meetings associated with Scrum, what meetings are prescribed, why they are necessary, and the recommended duration of each.

Also, if a Scrum Team is planning to release something EVERY Sprint (awesome!) then they would only really need to have a Sprint Planning meeting.

On the opposite end of the spectrum, a Product Owner might have many product backlog items (PBIs) identified with a firm intention of releasing a minimum viable product (MVP) represented by a specific number of PBIs, which constitutes more than what can fit in a Sprint or even several Sprints.

For the sake of projecting a POTENTIAL release date, it would be a good idea to walk through release planning. The team would NOT definitively plan all the upcoming Sprints, however. This is absolutely not the point. It’s simply to get an idea of how many Sprints there might be.

They would take the entire size of the release and divide by the velocity. This would give them roughly the number of Sprints for the release. If the velocity is not known, then they would take stab at walking through the items on the top of the backlog to figure out what they might be able to do in a Sprint and then use the size of that as the velocity.

Another scenario might be when there is a fixed release date and the Scrum Team would like to get a rough idea of what the scope MIGHT be for the release. This would involve taking the number Sprints there are from the start date to the release date and multiplying that by the velocity, or, again, the amount the team thinks it might do in a single Sprint. This will give the rough size of the scope that might be delivered by that date.

At a minimum, the entire Scrum Team would be involved in release planning. There might also be key stakeholders present to help provide clarification. However, the Product Owner should be the one running this show.

Because there can be many different notions of what a release is, there is no recommended duration for the release planning meeting. The ScrumMaster would reflect on the time being spent, whether it was moving forward and achieving its purpose, or whether there was some additional facilitation required.

During the “what” portion of the meeting, the Product Owner presents the product backlog to the Development Team. They may have already had discussions about each item and the acceptance criteria and taken the time to estimate those items that could potentially be pulled into the Sprint. If not, then this is the first thing that happens during Sprint Planning.

The Development Team looks at the product backlog starting with the very first item and decides if they can do this item in the upcoming Sprint. If so, they move to the next item and decide if they can do that in the upcoming Sprint, and so on. While they are considering whether they can do these items, they are thinking about upcoming PTO, holidays, and other factors that affect their capacity.

Once they have reached a point where they are “full” and unable to take on any additional work for the Sprint, the Product Owner confirms that he or she agrees with the items selected for the Sprint backlog. Then the Product Owner and Development Team together decide on a Sprint goal, which reflects the spirit of what they are trying to accomplish in the Sprint as expressed by the product backlog items selected for the Sprint Backlog.

Once this phase of Sprint Planning is complete, the Product Owner’s role is mostly complete. The Product Owner should not just disappear, however. They need to stick around to provide clarification to the Development Team and provide any other kind of support necessary as needed. I usually suggest that they take a seat off to the side somewhere in the meeting room where Sprint Planning takes place and work on updating the product backlog, etc.

The “how” phase of Sprint Planning involves the Development Team examining what they have just committed to. (Yes, I disagree with the Scrum Guide here and maintain that a team should treat this as a firm commitment, not just a “forecast.”) In doing so, they discuss any changes that might need to happen in the architecture, UI/UX design, database, automated test scripts, etc., in order to deliver shippable features by the end of the Sprint.

They may opt to break the features down into tasks, but this is not required by Scrum. Many teams do find it helpful to use tasks. Many others find it to be too much overhead to manage. Some teams that do tasks decide to estimate them in hours. Others find THAT to be too much overhead. Some teams identify tasks that follow the criteria in the Definition of Done. Because Scrum has no prescription around these practices, there is inherently a lot of flexibility for Development Teams to choose an approach that suits their needs and team dynamics.

Once the team is comfortable that they understand HOW to implement the features on the Sprint backlog, they are done with the Sprint Planning meeting.

However, I often emphasize the Development Team’s genuine reflection on its progress over simply going through the mechanical motions of answering questions without any contemplation or discussion. The “three question” format is telling, not discussing. Conveying the same information with less rigid structure is preferable, in my experience. Remember, our goal in all of this is NOT to follow Scrum (or any process) strictly and rigidly, but rather to gain insight into how we are doing by observing numerous feedback loops.

Obviously, the Daily Scrum should be done DAILY, especially for teams that are very new to Scrum. Over time, as the Scrum Team develops healthier, more regular and continuous patterns of communication, they might dispense with a formal Daily Scrum meeting. For instance, if a Development Team is collocated and sitting in the same cubicle block or in an enclosed, dedicated team room where there is a high degree of osmotic communication, then essentially the same information is being conveyed continuously throughout the day rather than being gathered from a single, formal feedback loop.

Also, if the Development Team is using an electronic tool to track the product backlog, Sprint backlog, Sprint burndown, etc., AND they are updating it diligently and regularly, then the tool will reflect the true state of the product increment at any given moment during the Sprint rather than a snapshot that is stale until the next day, that is, only updated once a day in the Daily Scrum.

Still, I strenuously caution Development Teams to continue having the Daily Scrum lest they fall away from Scrum altogether and its sound empirical mechanisms.

The two important points here are: 1) this is the OFFICIAL Scrum meeting for the Product Owner to express acceptance of the shippable product increment; and 2) this is the official opportunity for stakeholders to understand what’s going on with the product development effort and to provide feedback on the shippable product increment. Two more important points: 1) this should not be the ONLY time that the Product Owner has seen the completed features; and 2) this should not be the ONLY time that stakeholders are consulted about features and how the product is doing in terms of meeting their expectations.

Throughout the Sprint, whenever the Development Team feels that a feature has met the Definition of Done, they should contact the Product Owner and spend a modicum of time with them reviewing the functionality to ensure that it meets their expectations. Doing so will allow for earlier confirmation that they are on the right track and cut down on any unpleasant surprises by waiting until the end to find out that they missed the mark. If tweaks are necessary, the team can spend a bit more time making those tweaks, and then the feature will truly be done. If more work than a “tweak” is necessary, then the Product Owner knows that a new PBI will be necessary and can add that to the PBL. Once the Sprint Review comes along, that’s it—it’s too late for any changes, and there is a risk that items will not be accepted. They would then go back to the PBL for additional work in a future Sprint.

The Product Owner should be meeting with stakeholders regularly to discuss how the product development effort is progressing and to elicit new ideas for features from the stakeholders.

The Sprint Review meeting lasts one hour per week of the Sprint duration or less. Thus, if the Sprint is two weeks, the Sprint Review would be two hours or less.

However, taking the time to officially recognize the changes that have been occurring and spending some time to update things like the working agreements, Definition of Done, and other helpful guidelines will ensure that these don’t become stagnant and useless. Also, it may be the case that the Development Team is too heads-down with product deliverables to focus on improving the way it works. The Sprint Retrospective gives them an opportunity to reflect on these things and really focus on making improvements.

Two great resources for understanding the retrospective more effectively are Project Retrospectives by Norm Kerth and Agile Retrospectives by Diana Larsen and Esther Derby. Both emphasize the importance of maintaining a positive, constructive space while offering an opportunity for validation of feelings and closure, that is, at the end of each Sprint.

The retrospective should not be an open “misery session” where the entire group complains about how bad everything was or, worse, falling into a mob mentality as they attack someone or something openly. In fact, similar to the criminal justice idea of the “broken window theory,” once the conversation has taken a negative turn, it’s very difficult to refocus that conversation on a positive, constructive intent.

The Sprint Retrospective should be one hour per week of the Sprint duration and should be the very last meeting that is held during the Sprint. The entire Scrum Team is included so that improvements can be identified across the board and so that deeper bonds and relationships may be built among the Business, IT, and their coach (aka Product Owner, Development Team, and ScrumMaster).

What is important to know from a real world Agility (and thus, practical application) point of view is that the product backlog is undergoing continuous change. The Product Owner has several primary responsibilities, such as speaking directly with the customer(s) to determine valuable requirements, ensuring the overall value of the product to both customers and the organization, expressing the order of what to do next by ordering product backlog items in terms of value, and so forth.

The Product Owner adds, deletes, re-orders, identifies acceptance criteria, seeks estimates from the Development Team, and even splits PBIs continuously throughout the product lifecycle. There are no prescribed or set meetings in Scrum for when all this should occur.

In my experience, the organizations I have coached have found it useful to have an optional meeting once a week for one hour or less (USUALLY less) where the Product Owner presents any new items that have been identified since the last time they met. If there are no new items, they don’t meet. This is a practical application and not an official practice of Scrum.

So, don’t flip out and claim that you are “spending too much time in ALL these meetings.” Chances are, you are spending a LOT less time in much more productive and meaningful meetings than you ever have in your whole career.

I make a point of trying to keep the questions as anonymous as possible, so I have no idea who actually asked it, and it really doesn’t matter. Perhaps it is just an innocent case of semantics. Maybe it is a language barrier or challenge with English. It could even be someone’s idea of a joke or something sarcastic.

Whatever it is, I need to point out that the question itself is a bit paradoxical: “... make people accept self-management”? Make them?? Ouch.

The first thing we need to do is take a step back and examine our own conduct and what we are trying to accomplish overall. If our goal is to ENABLE people to be self-managing, then we need to realize that we can’t force them to do that. We need to somehow establish a condition where there is the ability for them to self-manage.

Overall, the spirit of Agile is to establish a vision of what needs to be done and then do whatever it takes to accomplish the vision. The vision represents what is valuable for both the customer and the organization. It reminds me of one of my favorite quotes by General George S. Patton:

Don’t tell a man how to do a thing. Tell him what you want done, and he’ll surprise you with his ingenuity.

Now, Patton was not a paragon of Agility, or self-management for that matter. However, there is a great deal of wisdom and applicability in many of his quotes. In this particular case, the way it applies to Agile is that by helping Development Teams understand WHAT the customer wants and WHAT the organization needs, they are better positioned to use their expertise and innovation to discover the HOW to deliver the solution. Therefore, instead of insisting on defining EVERYTHING for the Development Team or dictating a solution to them, help them understand the problem more effectively and then ask them to create the best solution possible.

Many times in my workshops, I conduct exercises with the class where I don’t provide ALL of the instructions necessary down to the nth degree. I will structure the exercise in such a way that the students need to make decisions or figure things out for themselves. As someone who has had a long history of being a command-and-control type manager, it’s absolutely nerve wracking to watch as the students struggle through things that are so obvious to me, especially in the beginning of the class. However, by lunchtime on the first day, the class has already figured out that I am only going to provide them with a vision and that they need to take chances in the exercises to see if they can deliver on my vision. By the end of the second day of class, I am usually confident that they will do well when they get back to the workplace, but frequently, they are facing a culture where self-management is not welcome.

Another thing that kills a team’s desire and ability to self-manage is lack of trust. Truth be told, I was a VERY staunch supporter of Ronald Reagan back in the day. However, one of the stupidest things he has ever said was:

“Trust, but verify.”

In his defense, he was merely acting on a suggestion from one of his researcher advisors on Russian culture and, consequently, trying to make good with Gorbachev by integrating this Russian proverb into his public persona (i.e., “doveryai, no proveryai”).

However, if we consider that trust is a conscientious decision to believe in the absence of proof, the statement “Trust, but verify” is really complete and utter nonsense. If you truly trust someone, you don’t need any proof, and if you require proof, then you don’t truly trust them. Thus, if we want to establish REAL trust with teams, we need to stop requiring proof of everything like extensive metrics.

On the other hand, this is a big part of why I feel that teams need to COMMIT to a Sprint backlog. As long as there are no external dependencies or impediments that are beyond the team’s control that prevent them from accomplishing the Sprint goal and the items on the Sprint backlog, then they really need to do what they say they are going to do. In return, leadership and the business need to have trust that the Development Team is going to accomplish what they say they will until there is evidence to the contrary; that is, if we get to the Sprint Review and the team has delivered nothing, and this is a result of their own lack of effort, etc., then the trust will be diminished.

Finally, providing an objective third party who is not a part of the development effort but can watch over everything to provide advice and guidance is also vital. I am referring to the ScrumMaster, of course. Some may say, “If you have a ScrumMaster overseeing the effort, then how is that NOT leadership?”

Well, it is leadership, but not management. The ScrumMaster should be a coach to the team. A football coach (either American or the rest of the world’s definition) isn’t out there on the field actually playing the game. The team is out there self-managing, self-organizing. The coach is there to communicate to the team: “Folks, THIS is what I am seeing out there ...” Each player is so busy playing their position the best that they can, they don’t have time to closely watch what every other player on the field is doing.

The ScrumMaster is keenly aware of what everyone is working on, what impediments there are, what’s going on with people from a personal perspective, how to motivate people, etc. Their main responsibilities are to protect the team, remove impediments, ensure that they have everything they need, and so forth. They also function as a mentor to the team in order to help them grow and mature to the point of being excellent at self-managing and self-organizing while they are executing. However, just as a football team would never go without a coach, regardless of how skilled they are, a Development Team should never be without a ScrumMaster to help guide them in their constant pursuit of excellence.

In the words of Franklin D. Roosevelt: “In the truest sense, freedom cannot be bestowed; it must be achieved.” A self-managing, self-organizing culture does not result from management declaring: “You are empowered!” Rather, when management shifts their focus from the tactical and executive to the strategic, trust will begin to emerge. Initially, there is a gap where decisions used to be handed down to the workers. However, when they realize no one is dictating every little step, they eventually fill the gap by assuming control and ownership of their own work.

Innovation can only thrive when teams are given a vision of the problem to solve and then the freedom to solve the problem. Too often, management seeks to enhance team performance by regulating and standardizing across the organization. Uniformity and conformity never produce innovative products that delight customers.

In the next chapter, we look to real stories from individuals who share their personal experiences with Agile adoption: the successes, failures, and lessons learned.