A few weeks ago we looked at the Definition of Done, which describes the conditions which must be satisfied before a team’s deliverables can be considered fit for release. That’s the acid test of what “Done” ought to mean. Can a team’s output actually be deployed into production and used immediately, or is any work still outstanding? We saw that a team’s Definition of Done will often fall short of this essential standard, and “technical debt” will be incurred as a result. This debt reflects the fact that certain things still need doing, no matter how small or trivial they might be held to be. Additional work will need to be carried out before the increment under development is truly usable. Perhaps there might be further tweaks to be done, or optimizations, or tests, or integration work with the wider product. Any such technical debt will need to be tracked, managed, and “paid off” by completing the outstanding work so the increment is finally brought up to snuff. Continue reading “Walking Through a Definition of Ready”
Google studied 180 teams through its Project Aristotle over two years. They were on a quest to find the common traits among the most successful ones. Going in, they assumed the best teams were comprised of the most skilled people. But that wasn’t the case. Instead, they found 5 core characteristics of high-performing teams:
- Structure and Clarity
- Psychological Safety
How can we incorporate these important characteristics into your team? Continue reading “Google Says These 5 Characteristics Can Make or Break a Successful Team”
Most of you probably have some tried-and-true best practices that you lean on to formulate requirements and articulate what needs to be done.
In many cases, that may involve the creation of use cases and user stories. While both are valuable tools, neither go quite far enough in defining the problem and desired outcome. But as I think you’ll see, a very simple change in the user story format will profoundly impact the finished product. Continue reading “How to Write Smarter User Stories for Product Design and Development”
Getting software updates to users quickly is paramount in today’s world. You know from your own phone, mobile, and computer usage that software updates for applications are a daily occurrence. We live in “internet time.” The ability to be quick and responsive with value to meet users’ needs can mean great success for a company, but the inability to do so could mean the death dive.
In order to survive in this world, you must be able to produce both swiftly and frequently. This is how you get ideas out fast and bring business value to customers. And, being able to do this requires agility. Working in the traditional Waterfall process of software delivery where there was a long drawn-out series of investigation, analysis, and planning doesn’t cut it anymore. Agile development allows you the framework that is critical to optimize planning, testing, and implementation. Agile development is a way to have faster cycle times, the goal being to achieve “internet time.”
Achieving Continuous Delivery and Continuous Deployment in the Solution Delivery Pipeline means your organization is nimble and can release updates to users in a responsive manner; these 2 phases in the pipeline are very important to the overall goal of fast, responsive deployments. However, sometimes there is confusion about what they are. In this article, we clarify the difference between Continuous Delivery and Continuous Deployment and describe how each fits into an Agile environment. Continue reading “Continuous Delivery vs. Continuous Deployment: An Overview”
Whether we’re limiting the times we hit the snooze button, increasing our attendance at the gym or improving our work performance, setting goals is essential in order to generate change. Yet, goals don’t always work: According to Statistic Brain Research Institute, a mere 9.2 percent of participants the institute surveyed said they’d successfully achieved their New Year’s resolutions so far in 2017. Continue reading “How to Set Goals That Will Turn an Average Team Into All-Stars”
Whilst the Scaled Agile Framework (SAFe) has evolved significantly over the years since inception, one area that has lagged is that of metrics. Since the Agile Release Train (ART) is the key value-producing vehicle in SAFe, I have a particular interest in Program Metrics – especially those produced on the PI boundaries. Continue reading “Revamping SAFe’s Program Level PI Metrics Part 1/6 – Overview”
While the DevOps movement and associated technologies have garnered much attention and fanfare, few have addressed the core issue—the handoff from development to operations. This blog post explains why release management is the bridge between development and operations, and how you can strengthen that bridge with the right approach, tools, teams, and processes. Continue reading “You Can’t Have a True DevOps Culture Without Effective Release Management”
How can you tell if you would benefit from having technical skills as a product owner? To answer this question, I find it helpful to look at how the role is applied. If you manage a digital product that end users employ, such as a web or mobile app, then you usually do not require in-depth technical skills, such as, being able to program in Java, write SQL code, or know which machine learning frameworks there are and if, say, TensorFlow is the right choice for your product. Continue reading “Do Product Owners Need Technical Skills?”
There’s a noticeable shift toward agile development taking place within the federal government. Driven by a need for accelerated application development and meeting internal customers’ needs on the very first attempt, agencies like the General Services Administration and Department of Homeland Security have begun to move away from traditional waterfall project management frameworks and toward iterative, agile frameworks like scrum. Continue reading “4 steps to agile success”
￼More development teams have adopted agile and lean ways of working to deliver better quality products faster. Despite their efforts, they’re still missing deadlines and churning out buggy software. Most of these teams are expected to solve business problems, but their work doesn’t align with business objectives. In fact, there’s a huge disconnect between development teams and the organizations they serve. Continue reading “Agile Can’t Succeed as an Island”
Sing it with me… “As a _user_ I want to _perform an action_ so I can _achieve an end result_.” This is great in theory, but writing good user stories is harder than it sounds. I’ve seen well-meaning product, design, and engineering folks take this approach to user stories and interpret them as magic words. Somehow, as long as we begin our task statement by uttering the “as a user” mantra, we’re magically taking a user-centered approach. Continue reading ““As a User” Needs to Stop”
￼After careful review of her harried work life, Charla, an IT manager, discovered that 20% of her time over the previous two months was spent managing escalations. It seemed that each interaction with her team ended with her feeling a need to exercise her authority to rescue them from a crisis. Continue reading “When to Solve Your Team’s Problems, and When to Let Them Sort It Out”
There is a well-known story about a cleaner at NASA who, when asked by JFK what his job was, responded “I’m helping to put a man on the moon.” This anecdote is often used to show how even the most mundane job can be seen as meaningful with the right mindset and under a good leadership. Continue reading “How to Make Work More Meaningful for Your Team”
Mistruths promoting the cure-all, Agile and DevOps, hurt everyone seeking a truly better way to deliver software. ING begun its agile transformation in 2010 with just three teams practicing agile. After seeing the success of those first three teams, ING transformed its entire development organization to Agile in 2011. While the transformation was deemed a success, ING found it wasn’t making much difference to the business, so it began forming its first DevOps teams. By 2014 ING executives felt that they weren’t receiving the benefits from Agile and DevOps for which they had hoped. Continue reading “Agile and DevOps are failing in Fortune 500 companies. It should be a wake-up call to all of us.”
Planning Poker relies on relative estimating, in which the item being estimated is compared to one or more previously estimated items. It is the ratio between items that is important. An item estimated as 10 units of work (generally, story points) is estimated to take twice as long to complete as an item estimated as five units of work. Continue reading “The Best Way to Establish a Baseline when Playing Planning Poker”
Agile promises rapidly evolving software and substantial business benefits, but it requires new habits from everyone: from IT and from business partners.
Agile development has largely become synonymous with digitization: senior business leaders have realized that their companies cannot take full advantage of digital tools and technologies without having new, amped-up processes for managing them. The value of these processes is immense. Continue reading “A Business Leader’s Guide to Agile”
Last summer, I changed companies. I had changed jobs before, but this time was different. Not only was I leaving a life of knowing everything (well, almost everything), but I also was leaving a product (LISA) I had invested the past 10 years of my life in supporting (like breaking up with a longtime girlfriend). Little did I realize then that I was about to start my Agile journey all over again. As a product manager, this journey was to take developers who were implementing cowboy methodologies to Agile Scrum. Along the way, we moved from JIRA and Grasshopper to IBM Rational and then to Rally (CA Agile Central) and managed not to lose all the stories and to keep some history of stories to source control for supported versions. The learning and the journey were amazing; there’s nothing like supporting a test product that drives Agile transformation but also helps your own development team adopt and understand Agile transformation. Continue reading “The SAFe Bet Over Agile Scrum for Enterprise Applications”
Lean-Agile Leaders need to understand an Enterprise’s current software development capitalization practice, as well as how to apply these principles in Agile development. Otherwise, the transformation to Agile may be blocked or, alternately, the company may not be able to correctly account for development expense.
Capital Expenses (CapEx) and Operating Expenses (OpEx) describe Lean-Agile financial tracking practices in a Value Stream budget. In some cases, CapEx may include capitalized labor associated with the development of intangible assets—such as software, intellectual property, and patents.
Enterprises provide funding to a SAFe portfolio to support development of the technical Solutions that allow the company to meet its business and financial objectives. These Lean Budgets may include both Capital Expense (CapEx) and Operating Expense (OpEx) elements. In accordance with accounting standards, some enterprises may capitalize (CapEx) some percentage of the labor involved in creating software for sale or internal use. Continue reading “CapEx and OpEx”
You have undoubtedly had team members complain at some point about the length of your Daily Scrums. Join the club.
I want to share two extremely simple things you can do to put an end to most of those complaints (I can’t promise they’ll get rid of all complaints—some people will always complain).
Since the Scrum guideline says that a Daily Scrum is not to be used for problem-solving, many Scrum Masters will note the problem during the Daily Scrum and then discuss it immediately afterward.
For example, if two hot issues are mentioned during the Daily Scrum, the Scrum Master might stop discussion of those topics. The Scrum Master will then bring the two topics back up after everyone has first had a chance to address the three questions of the Daily Scrum.
This leads to the team being there for longer than the standard timebox of 15 minutes for a Daily Scrum.
The first thing you should do is to end every Daily Scrum by announcing how long the meeting took. Do this right after everyone has addressed the three questions and before switching into problem-solving mode.
You might, for example, announce, “Thanks, everyone. That took twelve minutes.”
But then, remind everyone of any problems or issues that were brought up. Suggest that those who are needed stay to discuss or resolve them. If possible, facilitate the team splitting into more than one subgroup if more than one issue needs to be discussed.
Then, do the second thing that helps end complaints about the length of the Daily Scrum: announce that those who are not needed to resolve any of the issues being discussed can leave.
By taking these two actions:
1. Calling the Daily Scrum officially over and announcing how many minutes it took.
2. Telling team members who are not needed for further discussions that they can leave.
You will help team members from feeling that the Daily Scrum is exceeding its 15-minute timebox.
What Do You Think?
What have you done to eliminate complaints about the Daily Scrum? How have you helped your team see the value of this meeting? Please share your thoughts in the comments below.
Apache Beam Interview with Frances Perry
According to the Scrum Guide, Scrum is a framework within which people can address complex problems, and productively and creatively develop products of the highest possible value. It’s a tool organizations can use to increase their agility.
Within Scrum self-organizing, cross-functional, and highly productive teams do the work: creating valuable releasable product increments. Scrum offers a framework that catalyzes the teams learning through discovery, collaboration and experimentation.
A great Scrum Team consists of a Product Owner who maximizes value, a Scrum Master who enables continuous improvement and a Development Team who focus on delivering high quality product increments.
Agile & The Triple Constraint
For sure this sounds great!
But what are the characteristics of such a great Scrum team? This white paper will answer that question. It offers a detailed description of the characteristics and skills of a great Product Owner, Scrum Master and Development Team.
The Product Owner
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. It’s a one-person role that brings the customer perspective of the product to a Scrum Team.
The Product Owner is responsible for:
• Developing and maintaining a product vision and market strategy;
• Product management;
• Ordering and managing the Product Backlog;
• Involving stakeholders and end-users in Product Backlog refinement and backlog management;
• Alignment with other Product Owners when needed from an overall product, company or customer perspective.
A Great Product Owner…
• Embraces, shares and socializes the product vision. A great Product Owner represents the customers voice and creates a product vision together with the stakeholders. Every decision is taken with the product vision in mind. This ensures sustainable product development, provides clarity for the development team and increases the chances of product success drastically.
• Exceeds the customer’s expectation. A great Product Owner truly understands the customer’s intentions and goals with the product and is able to outstrip its expectations. Customer delight is the ultimate goal!
• Is empowered. A great Product Owner is empowered to take decisions related to the product. Sure, creating support for his decisions might take some time, but swiftly taking important decisions is a primary condition for a sustainable pace of the development team.
• Orders the product backlog. A great Product Owner understands that the product backlog should be ordered. Priority, risk, value, learning opportunities and dependencies are all taken into account and balanced with each other. For example, when building a house the roof might have the highest priority considering possible rain. But still it’s necessary to realize the foundation and walls earlier and therefore order them above the construction of the roof.
• Prefers face-to-face communication. A great Product Owner understands that the best way to convey information is face-to-face communication. User stories are explained in a personal conversation. If a tool is used for backlog management, its function is to support the dialogue. It never replaces the good old-fashioned conversation.
• Knows modeling techniques. A great Product Owner has a backpack full of valuable modeling techniques. He knows when to apply a specific model. Examples are Business Model Generation, Lean Startup or Impact Mapping. Based on these models he knows how to drive product success.
• Shares experiences. A great Product Owner shares experiences with peers. This might be within the organization, and outside it: seminars and conferences are a great way to share experiences and gather knowledge. In addition, writing down your lessons learned can be valuable for other Product Owners.
• Owns user story mapping. A great Product Owner should master the concept of user story mapping. It’s a technique that allows you to add a second dimension to your backlog. The visualization enables you to see the big picture of the product backlog. Jeff Patton wrote some excellent material about the concept of story mapping.
• Has a focus on functionality. A great Product Owner has a focus on functionality and the non-functional aspects of the product. Hours or even story points are less important. The goal of the Product Owner is to maximize value for the customer. It’s the functionality that has value; therefore this is the main focus for the Product Owner.
• Is knowledgeable. A great Product Owner has in depth (non-)functional product knowledge and understands the technical composition. For large products it might be difficult to understand all the details, and scaling the Product Owner role might be an option. However the Product Owner should always know the larger pieces of the puzzle and hereby make conscious, solid decisions.
• Understands the business domain. A great Product Owner understands the domain and environment he’s part of. A product should always be build with its context taken into account. This includes understanding the organization paying for the development but also being aware of the latest the market conditions. Shipping an awesome product after the window of opportunity closes is quite useless.
• Acts on different levels. A great Product Owner knows how to act on different levels. The most common way to define these levels is strategic, tactical and operational. A Product Owner should know how to explain the product strategy at board level, create support at middle management and motivate the development team with their daily challenges.
• Knows the 5 levels of Agile planning. Within Agile, planning is done continuously. Every product needs a vision (level 1) which will provide input to the product roadmap (level 2). The roadmap is a long range strategic plan of how the business would like to see the product evolve. Based on the roadmap, market conditions and status of the product the Product Owner can plan releases (level 3). During the Sprint Planning (level 4) the team plan and agree on Product Backlog Items they are confident they can complete during the Sprint and help them achieve the Sprint Goal. The Daily Scrum (level 5) is used to inspect and adapt the team’s progress towards realizing the Sprint Goal.
• Is available. A great Product Owner is available to the stakeholders, the customers, the development team and the Scrum Master. Important questions are answered quickly and valuable information is provided on time. The Product Owner ensures his availability never blocks the progress of the development team.
• Is able to say ‘no’. A great Product Owner knows how and when to say no. This is probably the most obvious but most difficult characteristic to master. Saying yes to a new idea or feature is easy, it’s just another item for the product backlog. However, good backlog management encompasses creating a manageable product backlog with items that probably will get realized. Adding items to the backlog knowing nothing will happen with them only creates ‘waste’ and false expectations.
• Acts as a “Mini-CEO”. A great Product Owner basically is a mini-CEO for his product. He has a keen eye for opportunities, focuses on business value and the Return On Investment and acts proactive on possible risks and threats. Everything with the growth (size, quality, market share) of his product taken into account.
• Knows the different types of valid Product Backlog items. A great Product Owner can clarify the fact that the Product Backlog consists of more than only new features. Fore example: technical innovation, bugs, defects, non-functional requirements and experiments, should also be taken into account.
• Takes Backlog Refinement seriously. A great Product Owner spends enough time refining the Product Backlog. Backlog Refinement is the act of adding detail, estimates and order to items in the Product Backlog. The outcome should be a Product Backlog that is granular enough and well understood by the whole team. On average the Development Team spends no more than 10% of the capacity of the Development Team on refinement activities. The way it is done isn’t prescribed and is up to the team. The Product Owner can involve stakeholders and the Development Team in backlog refinement. The stakeholders because it gives them the opportunity to explain their wishes and desires. The Development Team because they can clarify functional and technical questions or implications. This will ensure common understanding and increases the quality of the Product Backlog considerably. As a consequence, the opportunity to build the right product with the desired quality will also increase.
The Scrum Master
According to the Scrum Guide the Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.
The Scrum Master acts as a:
• Servant Leader whose focus is on the needs of the team members and those they serve (the customer), with the goal of achieving results in line with the organization’s values, principles, and business objectives;
• Facilitator by setting the stage and providing clear boundaries in which the team can collaborate;
• Coach coaching the individual with a focus on mindset and behaviour, the team in continuous improvement and the organization in truly collaborating with the Scrum team;
• Conflict navigator to address unproductive attitudes and dysfunctional behaviors;
• Manager responsible for managing impediments, eliminate waste, managing the process, managing the team’s health, managing the boundaries of self-organization, and managing the culture;
• Mentor that transfers agile knowledge and experience to the team;
• Teacher to ensure Scrum and other relevant methods are understood and enacted.
A Great Scrum Master…
• Involves the team with setting up the process. A great Scrum Master ensures the entire team supports the chosen Scrum process and understands the value of every event. The daily Scrum for example is planned at a time that suits all team members. A common concern about Scrum is the amount of ‘meetings’, involving the team with planning the events and discussing the desired outcome will increase engagement for sure.
• Understands team development. A great Scrum Master is aware of the different phases a team will go through when working as a team. He understands Tuckman’s different stages of team development: forming, storming, norming, performing and adjourning. The importance of a stable team composition is therefore also clear.
• Understands principles are more important than practices. Without a solid, supported understanding of the agile principles, every implemented practice is basically useless. It’s an empty shell. An in-depth understanding of the agile principles by everyone involved will increase the chances of successful usage of practices drastically.
• Recognizes and acts on team conflict. A great Scrum Master recognizes team conflict in an early stage and can apply different activities to resolve it. A great Scrum Master understands conflict isn’t necessarily wrong. Healthy conflict and constructive disagreement can be used to build an even stronger team.
• Dares to be disruptive. A great Scrum Master understands some changes will only occur by being disruptive. He knows when it’s necessary and is prepared to be disruptive enough to enforce a change within the organization.
• Is aware of the smell of the place. A great Scrum Master can have an impact on the culture of the organization so that the Scrum teams can really flourish. He understands that changing people’s behavior isn’t about changing people, but changing the context which they are in: the smell of the place.
• Is both dispensable and wanted. A great Scrum Master has supported the growth of teams in such a manner they don’t need him anymore on daily basis. But due to his proven contribution he will get asked for advice frequently. His role has changed from a daily coach and teacher to a periodical mentor and advisor.
• Let his team fail (occasionally). A great Scrum Master knows when to prevent the team from failing but also understands when he shouldn’t prevent it. The lessons learned after a mistake might be more valuable than some good advice beforehand.
• Encourages ownership. A great Scrum Master encourages and coaches the team to take ownership of their process, task wall and environment.
• Has faith in self-organization. A great Scrum Master understands the power of a self-organizing team. “Bring it to the team” is his daily motto. Attributes of self-organizing teams are that employees reduce their dependency on management and increase ownership of the work. Some examples are: they make their own decisions about their work, estimate their own work, have a strong willingness to cooperate and team members feel they are coming together to achieve a common purpose through release goals, sprint goals and team goals.
• Values rhythm. A great Scrum Master understands the value of a steady sprint rhythm and does everything to create and maintain it. The sprint rhythm should become the team’s heartbeat, which doesn’t cost any energy. Everyone knows the date, time and purpose of every Scrum event. They know what is expected and how to prepare. Therefore a complete focus on the content is possible.
• Knows the power of silence. A great Scrum Master knows how to truly listen and is comfortable with silence. Not talking, but listening. He is aware of the three levels of listening – level 1 internal listening, level 2 focused listening, level 3 global listening, and knows how to use them. He listens carefully to what is said, but also to what isn’t said.
• Observes. A great Scrum Master observes his team with their daily activities. He doesn’t have an active role within every session. The daily Scrum, for example, is held by the team for the team. He observes the session and hereby has a more clear view to what is being discussed (and what isn’t) and what everyone’s role is during the standup.
• Shares experiences. Great Scrum Masters shares experiences with peers. This might be within the organization, but also seminars and conferences are a great way to share experiences and gather knowledge. Of course writing down and sharing your lessons learned is also highly appreciated. And yes, for the attentive readers, this is exactly the same as for the Product Owner and the Development Team.
• Has a backpack full of different retrospective formats. A great Scrum Master can apply lots of different retrospective format. This ensures the retrospective will be a fun and useful event for the team. He knows what format is most suitable given the team’s situation. Even better: he supports the team by hosting their own retrospective. To improve involvement this is an absolute winner!
• Can coach professionally. A great Scrum Master understands the power of professional coaching and has mastered this area of study. Books like Coaching Agile Teams and Co-Active Coaching don’t have any secrets for him. He knows how to guide without prescribing. He can close the gap between thinking about doing and actually doing; he can help the team members understand themselves better so they can find news ways to make the most of their potential. Yes, these last few sentences are actually an aggregation of several coaching definitions, but it sounds quite cool!
• Has influence at organizational level. A great Scrum Master knows how to motivate and influence at tactic and strategic level. Some of the most difficult impediments a team will face occur at these levels; therefore it’s important a Scrum Master knows how to act at the different levels within an organization.
• Prevent impediments. A great Scrum Master not only resolves impediments, he prevents them. Due to his experiences he is able to ‘read’ situations and hereby act on them proactively.
• Isn’t noticed. A great Scrum Master isn’t always actively present. He doesn’t disturb the team unnecessary and supports the team in getting into the desired ‘flow’. But when the team needs him, he’s always available.
• Forms a great duo with the Product Owner. A great Scrum Master has an outstanding partnership with the Product Owner. Although their interests are somewhat different, the Product Owner ‘pushes’ the team, the Scrum Master protects the team. A solid partnership is extremely valuable for the Development Team. Together they can build the foundation for astonishing results.
• Allows leadership to thrive. A great Scrum Master allows leadership within the team to thrive and sees this as a successful outcome of their coaching style. They believe in the motto “leadership isn’t just a title, it’s an attitude”. And it’s an attitude everyone in the team can apply.
• Is familiar with gamification. A great Scrum Master is able to use the concepts of game thinking and game mechanics to engage users in solving problems and increase users’ contribution.
• Understands there’s more than just Scrum. A great Scrum Master is also competent with XP, Kanban and Lean. He knows the strengths, weaknesses, opportunities and risks of every method/framework/principle and how & when to use them. He tries to understand what a team wants to achieve and helps them become more effective in an agile context.
• Leads by example. A great Scrum Master is someone that team members want to follow. He does this by inspiring them to unleash their inner potential and showing them the desired behavior. At difficult times, he shows them how to act on it; he doesn’t panic, stays calm and helps the team find the solution. Therefore a great Scrum Master should have some resemblance to Gandalf. The beard might be a good starting point 🙂
• Is a born facilitator. A great Scrum Master has facilitation as his second nature. All the Scrum events are a joy to attend, and every other meeting is well prepared, useful and fun, and has a clear outcome and purpose.
The Development Team
According to the Scrum Guide the Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
• Self-organizing. They decide how to turn Product Backlog Items into working solutions.
• Cross-functional. As a whole, they’ve got all the skills necessary to create the product Increment.
• No titles. Everyone is a Developer, no one has a special title.
• No sub-teams in the Development team.
• Committed to achieving the Sprint Goal and delivering a high quality increment
A Great Development Team
• Pursues technical excellence. Great Development Teams use Extreme Programming as a source of inspiration. XP provides practices and rules that revolve around planning, designing, coding and testing. Examples are refactoring (continuously streamlining the code), pair programming, continuous integration (programmers merge their code into a code baseline whenever they have a clean build that has passed the unit tests), unit testing (testing code at development level) and acceptance testing (establishing specific acceptance tests).
• Applies team swarming. Great Development Teams master the concept of ‘team swarming’. This is a method of working where a team works on just a few items at a time, preferably even one item at a time. Each item is finished as quickly as possible by having many people work on it together, rather than having a series of handoffs.
• Uses spike solutions. A spike is a concise, timeboxed activity used to discover work needed to accomplish a large ambiguous task. Great Development Teams uses spike experiments to solve challenging technical, architectural or design problems.
• Refines the product backlog as a team. Great Development Teams consider backlog refinement a team effort. They understand that the quality of the Product Backlog is the foundation for a sustainable development pace and building great products. Although the Product Owner is responsible for the product backlog, it’s up to the entire team to refine it.
• Respects the Boy Scout Rule. Great Development Teams use the Boy Scout Rule: always leave the campground cleaner than you found it. Translated to software development: always leave the code base in a better state than you’ve found it. If you find messy code, clean it up, regardless of who might have made the mess.
• Criticizes ideas, not people. Great Development Teams criticize ideas, not people. Period.
• Share experiences. Great Development Teams share experiences with peers. This might be within the organization, but also seminars and conferences are a great way to share experiences and gather knowledge. Of course writing down and sharing your lessons learned is also highly appreciated. And yes, for the attentive readers, this is exactly the same as for the Product Owner.
• Understands the importance of having some slack. Great Development Teams have some slack within their sprint. Human beings can’t be productive all day long. They need time to relax, have a chat at the coffee machine or play table football. They need some slack to be innovative and creative. They need time to have some fun. By doing so, they ensure high motivation and maximum productivity. But slack is also necessary to handle emergencies that might arise; you don’t want your entire sprint to get into trouble when you need to create a hot-fix. Therefore: build in some slack! And when the sprint doesn’t contain any emergencies: great! This gives the team the opportunity for some refactoring and emergent design. It’s a win-win!
• Has fun with each other. Great Development Teams ensure a healthy dose of fun is present every day. Fostering fun, energy, interaction and collaboration creates an atmosphere in which the team will flourish!
• Don’t have any Scrum ‘meetings’. Great Development Teams consider the Scrum events as opportunities for conversations. Tobias Mayer describes this perfectly in his book ‘The Peoples Scrum’: “Scrum is centered on people, and people have conversations. There are conversations to plan, align, and to reflect. We have these conversations at the appropriate times, and for the appropriate durations in order to inform our work. If we don’t have these conversations, we won’t know what we are doing (planning), we won’t know where we are going (alignment), and we’ll keep repeating the same mistakes (reflection).”
• Knows their customer. Great Development Teams know their real customer. They are in direct contact with them. They truly understand what they desire and are therefore able to make the right (technical) decisions.
• Can explain the (business) value of non-functional requirements. Great Development Teams understand the importance for non-functional requirements like e.g. performance, security and scalability. They can explain the (business) value to their Product Owner and customer and hereby ensure its part of the product backlog.
• Trust each other. Great Development Teams trust each other. Yes, this is obvious. But without trust it’s impossible for a team to achieve greatness.
• Keep the retrospective fun. Great Development Teams think of retrospective formats themselves. They support the Scrum Master with creative, fun and useful formats and offer to facilitate the sessions themselves.
• Deliver features during the sprint. Great Development Teams deliver features continuously. Basically they don’t need sprints anymore. Feedback is gathered and processed whenever an item is ‘done’; this creates a flow of continuous delivery.
• Don’t need a sprint 0. Great Development Teams don’t need a sprint 0 before the ‘real’ sprints start. They are able to deliver business value in the first sprint.
• Acts truly cross-functional. Great Development Teams not only have a cross-functional composition and act truly cross-functionally. They don’t talk about different roles within the team but are focused on delivering a releasable product each sprint as a team. Everyone is doing the stuff that’s necessary to achieve the sprint goal.
• Updates the Scrum board themselves. Great Development Teams ensure the Scrum/team board is always up-to-date. It’s an accurate reflection of the reality. They don’t need a Scrum Master to encourage them; instead they collaborate with the Scrum Master to update the board.
• Spends time on innovation. Great Development Teams understand the importance of technical/architectural innovation. They know it’s necessary to keep up with the rapidly changing environment and technology. They ensure they have time for innovation during regular working hours, and that it’s fun and exciting!
• Don’t need a Definition of Done. Great Development Teams deeply understand what ‘done’ means for them. For the team members, writing down the Definition of Done isn’t necessary anymore. They know. The only reason to use it is to make the ‘done state’ transparent for their stakeholders.
• Knows how to give feedback. Great Development Teams have learned how to give each other feedback in an honest and respectful manner. They grasp the concept of the ‘Situation – Behavior – Impact Feedback Tool’ and hereby provide clear, actionable feedback. They give feedback whenever it’s necessary, and don’t postpone feedback until the retrospective.
• Manages their team composition. Great Development Teams manage their own team composition. Whenever specific skills are necessary, they collaborate with other teams to discuss the opportunities of ‘hiring’ specific skills.
• Practice collective ownership. Great Development Teams understand the importance of collective ownership. Therefore they rotate developers across different modules of the applications and systems to encourage collective ownership.
• Fix dependencies with other teams. Great Development Teams are aware of possible dependencies with other teams and manage these by themselves. Thereby ensuring a sustainable development pace for the product.
• Don’t need story points. Great Development Teams don’t focus on story points anymore. They’ve refined the product backlog so that the size for the top items don’t vary much. They know how many items they can realize each sprint. Counting the number of stories is enough for them.
About the Author
Barry Overeem is an Agile Coach at Prowareness and Professional Scrum Trainer at Scrum.org. He is an active member of the Agile community and shares his insights and knowledge by speaking at conferences and writing articles. Since 2000 he fulfilled several roles with a software development environment, these vary from application consultant, project manager and team lead. Since 2010 his primary focus is applying the Agile mindset and the Scrum Framework. Barry is specialized in the role of the Scrum Master and helping people understand the spirit of Scrum and hereby using the Scrum framework better. Due his own practical experience as a Scrum Master, Barry gained a lot of experience with starting new teams, coaching teams through the different stages of team development and applying different types of leadership. Sharing these experiences and hereby contributing to other persons growth is his true passion!