A Recap of Lean Agile DC 2018

CC Pace spent an informative day at the Center for Innovation Technology (CIT) event in Herndon, VA: Lean Agile DC.  Jason Velentino (Director, Digital Reliability Engineering at Capital One) kicked off the conference with a great presentation on DevOps and his journey through incorporating cloud and a DevOps culture at such a large organization. It is rewarding for CC Pace to have been a part of the Agile adoption at Capital One, providing Agile Coaching and Training over the past five years and to see the evolution of Agile, which Capital One has made part of their everyday culture.

Another great presentation and discussion on Agile Engineering was lead by Jose Mingorance, and Carlos Rojas of Fannie Mae. They have pulled together a lot of ideas from Agile leaders to provide Fannie Mae with an exciting assessment and plan to drive business value throughout their organization through advancing Agile engineering practices. It was interesting to see their plans and the excitement surrounding this initiative.

Finally, Dean Chanter, also from Capital One, lead a great discussion on Joshua Kerievsky’s Modern Agile principles. Dean spoke about his journey towards ‘modern Agile’ at Capital One and how those principles are at the cornerstone of their advancement in their Agile transformation as an organization. As Capital One continues their trajectory into being Agile leaders in the Financial Services market, this will be an interesting case study to keep an eye on! We look forward to next year and seeing how everyone has progressed.

Thoughts on Agile DC 2017
In early February of 2001, a small group of software developers published the Agile Manifesto. Its principles are now familiar to countless professionals. Over the years, Agile practices seem to have gained mainstream appeal. Today it is difficult to find a software developer, or even a manager who has never heard of Agile. Having been a software developer for over 15 years, to me, Agile methodologies appear to embody a very natural way of producing software, so in a lot of ways, Agile conferences produce a “preaching to the choir” effect as well. As I attended the Agile DC 2017 conference, I wanted to remove myself from the bubble and try to objectively take a pulse of the state of Agile today. I also wanted to learn about the challenges that Agile seems to continue to face in its adoption at the enterprise level.

Basic takeaways
As I listened to various speakers and held conversations with colleagues and even one of the presenters, it appears that today the main challenges of adopting Agile no longer deal specifically with software engineering. That generally makes sense, given the amount of literature, combined experience and continuous improvement software development teams have been able to produce as Agile has matured from a disruptive toddler into a young adult. The real struggle appears to be in adoption of Agile across other business units, not so much IT. Why is that? I believe the two main reasons for the struggle can be attributed to organizational culture, but most importantly lack of knowledge in relation to team dynamics and human psychology.

Culture
Agile seems to continue to clash with the way business units are organized. Some hierarchical structures may produce very siloed and stovepiped groups that have difficulty collaborating with one another. While this may appear as an insurmountable problem, there is at least one great example of how Agile organizations have addressed it. We can point to DevOps as a great strategy of integrating or streamlining traditionally separate IT units. Software development teams and IT Operations teams have traditionally existed in their respective silos, often functioning as completely separate units. There was a clear need of streamlining collaboration between the two to improve efficiency and increase throughput. As a result, DevOps continues on a successful path. In regards to other business units, “Marketing” may depend on “Legal” or “Product Development” may depend on “Compliance”. There may be a clear need to streamline collaboration between these business units. One of my favorite presentations at the conference was by Colleen Johnson entitled “End to End Kanban for the Whole Organization”. By creating a corporate Kanban board, separate business units were able to collaborate better and absorb change faster. One of the business unit leaders was able to see that there were unnecessary resources being allocated to supporting a product development effort that was dropped (into the “dropped” row on the board). Anecdotally, this realization occurred during a walk down the hall and a quick glance at the board.

Education
When it comes to software development, Agile appears to contain some key properties that make it a very logical and a natural fit within the practice. Perhaps its success stories in the software development community is what produced a perception that it applies specifically to software engineering and not to other groups within an organization. It seems to me that one of the main themes of the conference was to help educate professionals who possess an agnostic view related to the benefits of an Agile transformation. I believe that continuous education is critical to getting business unit leaders to embrace Agile at the enterprise level. Some properties of Agile and its related methodologies addresses some important aspects of human psychology.  This is where the education seems to lack. There is much focus on improvement in efficiency and production of value, with little explanation of why these benefits are reaped. In simple terms, working in an Agile environment makes people happier. There are “softer” aspects that business leaders should consider when adopting Agile methodologies. Focus on incremental problem solving provides a higher level of satisfaction as work gets completed. This helps trigger a mechanism within the reward system of our brain. Continuous delivery helps improve morale as staff is able to associate their immediate efforts to the visible progress of their projects. Close collaboration and problem solving creates strong bonds between team members and fosters shared accountability. Perhaps a detailed discussion on team dynamics and psychology is a whole separate topic for another blog, but I feel these topics are important to managing the perception of the role of Agile at the enterprise level.

Final thoughts
It is important to note that enterprise-wide Agile transformations are taking place. For example, several speakers at the conference highlighted success stories at Capital One. It seems that enterprise-wide adoption is finally happening, albeit very incrementally, but perhaps that is the Agile way.

Learn more about Agile Coaching.

Why user stories don’t always make sense:

I am doing a lot of work with business units adopting Scrum or Kanban. As I explain to them, writing a user story in the correct format may not add any value to them. User Stories date back to Extreme Programming (XP). In the first part of the story “as a _____”, the blank is filled in with the user. As Product Owners identify users, they should be creating Personas that identify key user attributes. A millennial user will have different usage of an application than a retiree. These personas help the developer think about the user as they design how they will implement each user story. When a business unit is simply trying to get transparency about the work they are doing, their stories may be more of the “spike” or “technical” story variation. My question to these teams is can you identify the person receiving value when implementing the story? They think about this and sometimes think it is just their manager, or the company. The most common mistake is that the person doing the work is writing the story with their job title in the first blank; or getting a story with “As a Product Owner”. When using Scrum or any other Agile method for non-software work, I believe going through the effort of writing the story in User Story format As a ______, I want _______, So that______, just adds extra overhead, and no true value to the person doing the work. Instead, I recommend they save themselves that overhead and simply write “Create ____” or “Do _____”. The real value is in having good Acceptance Criteria. For example, if I want to have use a backlog for chores at home a User Story might look like:

As a Parent
I want the dishes done
So that the kitchen will be clean

Acceptance Criteria:
1 – No dishes remain lying around the house
2 – All dishes are in the dishwasher
3 – All kitchen surfaces are clean

Well this is great, I could just as easily write “Do the dishes” as my story keeping the acceptance criteria, so it is clear what is required.

For me, working in an Agile manner means reducing waste while increasing value. If you aren’t creating an application with users, going the distance to write a complete User Story is just waste. In Scrum there are four things in your product backlog, take advantage of that mindset. Skip the formality of the User Story.

Many people ask, what is the distinction between an Agile adoption and an Agile transformation? The former being the adoption of an Agile method and tools, and the latter encompassing those plus the people, culture and mindset shift that must accompany the adoption for an organization to fully realize the benefit.

The real difference between adoption and transformation is that adoption fails and transformation sticks. You don’t really choose one over the other – people that fail to see the difference often do the adoption because they don’t realize that culture is what makes it really stick. Most organizations start with the adoption of a method at the team level within IT. Some will also covey the message to ‘do Agile’ from the top. However, this type of adoption rarely sticks. Middle management is lost in the shuffle, often just waiting out the change and expecting it to fail. The focus is on processes and tools – not people and interactions. The mindset of transparency, adaption and continuous improvement is misplaced in favor of mechanics and metrics.

A true transformation requires the organization to think and ‘be Agile’.  It requires the organization to look at their people, organization and culture, as well as their process and tools.  An organization will move through stages improving and absorbing changes in these areas.  Typically, an organization will begin with a pilot with one or more teams.  This allows the organization to best see how Agile will affect the current process and roles, and help to uncover gaps and potential areas of conflict, such as, central versus decentralized control.

It takes time to move through all the stages that are mapped out for the process, and much depends on the attitude and behaviors of leadership. Does leadership model the behavior they seek in others? Do they look to break down barriers to value delivery? Do they reward the team and system success rather than individual or functional success? Another important factor is that the organization knows what it is driving towards. This vision and accompanying goals are what will drive the pilot and future transformation activities. This alignment is the first step. As CC Pace continues to work with companies through this process we see the positive effects gained throughout each organization.

If you are interested in learning more about Agile Transformations, join us on Tuesday, June 13, for a free webinar on the topic! Click here to register.

No matter what kind of work we do, we look for feedback from our customers, our co-workers and our peers. Why do we do that? To improve and to get better at what we do.  The same thing applies to Agile teams and programs, no matter what methodology the team is following: Scrum, Kanban, XP, SAFe, LeSS, or DAD.

A good retrospective is the key to helping teams improve what they are doing. It helps them identify and streamline processes which can create efficiencies and get them to that next level of maturity.  Hard to believe, but this is the event which is most commonly ignored or taken lightly. Teams often feel they are too busy and do not have time to retrospect.  This makes the team get into a ‘Plan and Do – Plan and Do’, vicious cycle. They never stop to reflect and adjust and then they complain Agile doesn’t work.

An Agile Methodology isn’t magic and it doesn’t solve all problems by itself.  It makes the problems transparent, clear and appear sooner in a project’s lifecycle. But to identify the problems and to find out what can be done differently to improve the processes, the teams need to retrospect.

So why don’t the teams do retrospectives?  Here are some of the reasons they give:

• Don’t have time just to talk, it’s a waste of time
• Retrospectives are boring
• No one takes any actions from the retrospectives so why bother
• Same monotonous technique
• Unplanned meeting
• High performing team already, nothing more to improve on
• No participation

So how do you make retrospectives interesting, add value to the team and make them a place where the team members can express their opinions without any repercussions?

First of all, the retrospectives should follow the “Vegas Rule” – what happens in Retrospectives stays amongst the team members.  All of the information is shared in this container of trust and all team members and facilitators should respect the container.  Information or data in the retrospectives is collected with the sole purpose of making the team better and improving processes.  The information should not be used as performance management feedback.

Secondly, and most importantly, it is not intended to be a finger pointing session or to point out the skill or knowledge gaps in any individual team member. Retrospectives should always be respectful and be conducted professionally by a skilled facilitator (usually a Scrum Master).

Thirdly, the retrospectives should be done by selecting interesting activities that engage all team members.  The activities should be relevant to what is happening in the team. They should let the entire team collect data, learn the insights and decide on what actions they can take together to improve.

Fourthly, the retrospectives should be made exciting! The teams which asks the same dreaded questions – what did we do well, what did we not do so well or any suggestions for improvements at the end of every sprint really gets boring and monotonous, not only for the team but for anyone facilitating the retrospective as well.

Create an environment of trust, honesty and make room for some creative retrospective ideas.  It should be planned in advance so the team feels like it is a treat being part of a retrospective after the hard work in the sprint. It should allow the team to think about innovative ways in which they can adjust and make themselves and the processes better. The book by Ester Derby on making retrospectives great is an excellent resource and so is the website Tastycupcakes.org for activity ideas.

Next, what about the findings and action items from the retrospectives? Many tools like Version One have a section wherein the output of  retrospectives can be created, stored and referenced in next retrospective. The best thing is to prioritize the resulting action items, assign them owners and place the list both in the online tool for distributed team members and on the physical board as an Information Radiator. Do a check-in on the retrospective action items and see if they are completed.  Items can be added to the team’s backlog and be accepted by the team’s PO.

Just collecting feedback and forgetting about the retrospectives is what makes most people discouraged from holding retrospectives.  When people feel that no action is taken and nothing changes, they wonder why they should keep on wasting time with this retrospective exercise.

Participation from all team members is key.  Especially if you have some very quiet team members and others who have a lot of ideas and take over the meeting. Good facilitation skills come-in handy to address this concern. If the facilitator knows that some team members are reticent to jump in and be part of the conversation, they can ask direct questions to engage those team members so that everyone is heard and valued.

Lastly, no team is so high performing that they cannot retrospect or find anything else to improve.  They might have found other mechanisms of inspecting what they are doing and how to adjust, such that they do not wait until the end of the sprint for this formal retrospective session.  But they are still doing a retrospective, even if it’s all the time.

When I am out providing Agile classes, the topic of what Scrum Masters do all day comes up pretty frequently. Attendees ask questions like; “How many teams can a ScrumMaster be part of?”, and “Do Scrum Masters just run meetings?”. As a veteran of Scrum, I am still surprised at how little organizations understand about the ScrumMaster role. But let’s face it, attending a 2 or 3 day Certified ScrumMaster course provides only an introduction to the Agile Framework, Scrum Events and Roles. Experience and a desire to truly understand what it means to be Agile and how Scrum embraces these principles takes time. It’s an ongoing learning that extends beyond just getting certified.

So let’s start with the basics. The single word most often used to describe the ScrumMaster role is “Facilitator”. Here is the Merriam-Webster’s definition

Definition of Facilitator:

one that facilitates; especially: one that helps to bring about an outcome (as learning, productivity, or communication) by providing indirect or unobtrusive assistance, guidance, or supervision <the workshop’s facilitator kept discussion flowing smoothly>

How does a ScrumMaster facilitate while being “indirect or unobtrusive”? First, you need to understand where your team and organization fit on a scale from just starting their journey to practicing best practices as a highly performing team. I say this because new teams do need a little more “hand holding”, than teams that have been together for a while, and are experienced following Scrum. The ideal goal is to get the teams to work via self-organizing, while motivating them by ensuring they have the right tools and support. ScrumMasters promote the team’s work, not their own work.

The Scrum Guide (see http://www.scrumguides.org/scrum-guide.html) lists three groupings of work for the Scrum Master: 1. Service to the Product Owner 2. Service to the Development Team 3. Service to the Organization. This requires that the ScrumMaster have several skills they can call on at any time depending on where the need is. Nowhere in the Scrum Guide does it say the ScrumMaster is the boss, the secretary, or the project manager of the team.

So, let’s go back to what it means to be a facilitator by looking at a scrum event. ScrumMasters do typically organize getting all the scrum events set up. Ideally scrum events are on a cadence to occur at the same time, and in the same place whenever possible. ScrumMasters facilitate events by ensuring the space is appropriate for the job at hand, all needed supplies are available, and that the appropriate attendees have been invited. The following is an example of how Sprint Planning is facilitated by the ScrumMaster:

Sprint Planning
The goal of Sprint Planning is to identify what can be delivered and how the work will be achieved.

The Scrum Master ensures all stories being presented in Sprint Planning meet the Definition of Ready by working with the Product Owner in advance of the meeting.

The ScrumMaster provides the container for the meeting, and turns it over to the Product Owner to work with the team providing the sprint goal and a conversation to promote a thorough understanding of the stories proposed for the upcoming sprint.

The team moves on to designing how they will do the work and tasking the stories, while the ScrumMaster listens and watches to ensure there is a shared understanding and that the team members have an equal voice. The ScrumMaster can facilitate by ensuring the team stays focused and doesn’t get stuck by asking questions, inviting others with specific technical expertise to join the conversation, and managing the time box of the event.

The final step is when the ScrumMaster calls for the team to commit to delivering the work.

There are many great web articles that list things a Scrum Master does. Here are a couple of good ones:

https://www.mountaingoatsoftware.com/agile/scrum/scrummaster
http://agiletrail.com/2011/11/14/42-tasks-for-a-scrum-masters-job/

Aside from facilitators, ScrumMasters are also the team’s protector, an overall evangelist and enforcer of the Scrum method, and a coach.

Surprised? What does the ScrumMaster do in your organization? Are there improvements that can be made? I welcome your feedback, questions and comments.

In Scrum, the User Story represents the main item in the Product Backlog. However, it is not the only item in the backlog. So let’s take a look at other items in the Product Backlog.

According to the Scrum Guide, “The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.”

For the purpose of simplicity, we group the backlog into four types of items:

1. User Stories
2. Technical Stories
3. Spikes
4. Defects

Let’s take a look at each type of item.

User Story
Written in the format: As a Type of User, I Want to do something, So that why do I want it. User stories are not complete without Acceptance Criteria and a discussion with the team to gain the full requirements of the story. User stories cover features, functions, enhancements, and epics. Typical guidance is that a user story can be completed in 2 days or less, while some experts say the work of the team on a story may last up to a week. Whether you call large User Stories epics, themes, or features may depend on what tool you are using, or how you were trained. User Stories originate from XP where any large story needing to be broken down was called an Epic. As these large stories were broken down, we could actually tear up the Epic as it was being replace with multiple smaller stories. Product Owners may not have the skills to break stories down as small as they need to be for a Sprint. This is where the team comes in during grooming/refinement to help break down stories and discover gaps. Our tools (Version One, Rally, Jira, etc) allow us to maintain a parent child relationship using the labels like Epic, Theme, or Feature.

For tips on writing user stories check out this link.

User Stories can be written by anyone. They are often written during user story workshops where the team and stakeholders are together brainstorming user actions and system needs. The goal of the Product Owner is to thoroughly understand stakeholders needs in order to create and explain the User Stories in the backlog. For me, the PO or their surrogate are the main writers of user stories for end user applications. PO’s are the ones that will typically be engaging stakeholders. So while they may get some help in writing the stories, they are still the ones accountable for ensuring complete understanding, and to accept the story as the work is completed.

Technical Stories
Technical Stories represent any technical work the team must undertake during a sprint. While it is possible to use the typical user story format by identifying ‘the who’ as something that isn’t really a person, like “System X”. However, I ask teams I’m working with: is there any value in writing Technical stories in this format? For me, where there is no benefit, there is no reason to write technical stories in the user story format. A simple statement will work, e.g. “upgrade test tool”. While the format of a user story isn’t needed, it is still important to include acceptance criteria. Team members typically write these stories, and let the PO know where in the backlog they should sit in order to be completed in a timely manner, often as a predecessor to doing other user stories.

For more on writing Technical Stories look here check out what Mike Cohn says about using the FDD format here.

Spikes
Spikes are done for knowledge acquisition. Spikes should be time-boxed, and have specific acceptance criteria. A team member may ask for a spike in order to do some research, proof-of-concept, or prototyping to gain knowledge prior to working on a set of user stories. There is no reason to write spike in user story format. The maximum duration for a Spike is the length of a sprint. Another attribute of Spikes, is that they should be the exception and not the rule.

For more on Spikes see this article.

Defects
As users work with the system, and testers test the system, bugs or other defects may be found. For me, these are not the same as rejecting a current user story because it fails testing. User Stories that fail testing are rejected and reworked within the sprint if time allows. If time doesn’t allow, the PO can decide if the story will be in the next sprint or not, and the team will not get points for the story until it passes test.

As other defects or bugs are found in the system new user stories are written to identify the desired functionality. The PO will stack rank these PBI’s along with all other stories.

Have you heard that not all Agile Transformations are successful? Have you wondered what makes some transformations more successful than others? Are you wondering if your organization can be successful?

Here is a little analogy to think about. I recently lost 40 pounds on an eating transformation plan, or more simply a diet. I don’t like to call it a diet, because if I ever go back to my old way of eating I’ll likely gain my weight back. Also if I don’t follow the basic guidelines of the diet, I may not lose weight at all.  So what does this have to do with being successful at Agile?

When organizations pick and choose what principles to follow in Agile, it’s like low carb dieters choosing to still eat potatoes, or white bread on their diet. While they may see some improvements, overall they are not setting themselves up for success on this plan. The diet gets blamed rather than how the dieter chose to implement the diet.

When preparing for a transformation, the first step is to get the foundational pieces right. Learn about the plan. Prepare your house by cleaning out your cupboards and fridge, and shop for the good stuff to replace the bad stuff. Learn what the rules of your plan are, and set a date to begin. Note, a new eating plan works better if everyone in the house is on the same plan! Then measure the results, and make corrections as needed.

In an Agile transformation, the steps are much the same. Identify what method you want to follow within the Agile framework. Get everyone onboard by helping them learn about the methodology. Prepare your “house” by looking at the organizational structure and identifying what will work within the transformation and what won’t. Make a decision to replace the practices that don’t fit in the transformation with practices that will support a successful transformation. Inspect and Adapt to keep improving and making course corrections along the way.

So what if your organization doesn’t want to follow the plan to the letter? It’s OKAY… BUT the organization needs to know the impact of alterations in the plan. If I can’t give up my potatoes what does that mean? Will I see the same success rate? How can I compensate for keeping my potatoes?

Some Agile principles are more easily adapted than others. I can counteract teams not being co-located for “face-to-face” interactions, by providing great tools for them. I can bring those team members together for planning sessions, or other occasions to help build the team rapport, and offset the lack of co-location. Other principles aren’t so easily adapted. A poor company culture where trust and empowerment are lacking, may prove to be too much to overcome, leaving the organization with unmotivated and un-empowered teams.

If your transformation has hit a plateau, or doesn’t seem to be working. It may be time to take a look at how you are following the new plan, and where your potato-eating cheats are causing you bloat, and derailing your success. It may not be the method, but rather how you are following it.

I’m just returning to work after Spring Break in Cancun. I’ve met some lovely people while enjoying the sunshine. As I chatted with those beside me at the beach and alongside the pool, two common questions are asked: What is your name? and What do you do for a living? The answer to the first question is easy, but the answer to the second question is much longer. Why? Because I can’t just stop with “I’m a trainer”. I enjoy talking about Agile and Scrum, and explaining the basic framework. I enjoy sharing with others how they can apply what I teach to just about anything. I enjoy sharing Agile stories because Agile works, and I like talking about how companies can adopt an Agile mindset.

When I start talking to someone about Agile, I begin by explaining first how past processes have fallen short. The trials and tribulations of a 1 or 2 year project plan, managing risk, reaching or missing milestones, and change requests to re-baseline the plan for any number of reasons come to mind. All with a real concern of delivering something that misses the mark in “delighting the customer”.  Waterfall projects often have cost overruns, extended delivery dates, and a plethora of change requests that aren’t discovered until near the end of the project during User Acceptance Testing (UAT).  For these reasons, Waterfall just doesn’t feel like the best choice to deliver software anymore.

I then move on to talk about why I, and so many others, choose Agile processes to build software today. So here is a little of what I talk about:

• Continuous engagement with the customer and other stakeholders is key
• Seeing progress through continuous delivery enables better feedback
• Reduced risk and waste, which can save money and heartache
• Adapting to change quickly, which allows for the customer to respond to market changes
• Better quality deliveries by testing early and often
• Happier employees as a result of practicing the 12 Agile Principles

It isn’t magic, and it isn’t necessarily an easy transition to make. To become a truly Agile organization takes a true shift in how we and everyone else in our organization thinks about how work is performed both internally, and externally with our customers.

Yes, I am a bit of an evangelist. Sometimes I want to shout from rooftops “people get it together, follow Agile principles”, “walk the talk”, “quit being stuck in the past”. Our world is evolving every day. To keep pace with our competitors, we need to evolve too. Agile is an umbrella term for a number of methodologies including Kanban and Scrum. Today we find that Agile isn’t just for software anymore. The principles and methods can be followed just about anywhere to greatly improve our ability to deliver just about anything. That’s why I’m not just a trainer, but a believer.

No matter what kind of work we do, we look for feedback from our customers, our co-workers and our peers. Why do we do that? To improve and to get better at what we do.  The same thing applies to Agile teams and programs, no matter what methodology the team is following: Scrum, Kanban, XP, SAFe, LeSS or DAD.

A good retrospective is the key to helping teams improve what they are doing. It helps them identify and streamline processes which can create efficiencies and get them to that next level of maturity.  Hard to believe, but this is the event which is most commonly ignored or is taken lightly. Teams often feel they are too busy and do not have time to retrospect.  This makes the team get into a Plan and Do – Plan and Do vicious cycle. They never stop to reflect and adjust and then they complain Agile doesn’t work.

An Agile Methodology isn’t magic and it doesn’t solve all problems by itself.  It makes the problems transparent and clear and appear sooner in a project’s lifecycle. But to identify the problems and to find out what can be done differently to improve the processes, the teams need to retrospect.

So why don’t the teams do retrospectives?  Here are some of the reasons they give:

• Don’t have time just to talk, it’s a waste of time
• Retrospectives are boring
• No one takes any actions from the retrospectives so why bother
• Same monotonous technique
• Unplanned meeting
• High performing team already, nothing more to improve on
• No participation

So how do you make retrospectives interesting, add value to the team and make them a place where the team members can express their opinions without any repercussions?

First of all, the retrospectives should follow the Vegas Rule – What happens in Retrospectives stays amongst the team members.  All of the information is shared in this container of trust and all team members and facilitators should respect the container.  Information or data in the retrospectives is collected with the sole purpose of making the team better and improving processes.  The information should not be used as performance management feedback.

Secondly and most importantly, it is not intended to be a finger pointing session or to point out the skill or knowledge gaps in any individual team member. Retrospectives should always be respectful and be conducted professionally by a skilled facilitator (usually a Scrum Master).

Thirdly, the retrospectives should be done by selecting interesting activities that engage all team members.  The activities should be relevant to what is happening in the team. Retrospectives should enable the entire team collect data, learn the insights and decide on what actions they can take together to improve.

Fourthly, the retrospectives should be made exciting. The team which asks the same dreaded questions – what did we do well, what did we not do so well and are there any suggestions for improvements at the end of every sprint usually don’t get to the crux of the matter.  The retrospectives get boring and monotonous.

Create an environment of trust and honesty and make room for some creative insights.  Retrospectives should be planned in advance so the team feels like it is a pleasure being part of the retrospective after all the hard work in the sprint. It should allow the team to think about innovative ways in which they can adjust and make themselves and the processes better. A book by Ester Derby on ways to use creative exercises in retrospectives is an excellent resource and so is the website Tastycupcakes.org.

Next, what about the findings and action items from the retrospectives? Many tools like Version One have a section wherein the retrospectives can be created, stored and referenced in the next retrospective. The best thing is to prioritize the items, assign them owners and place the list both in the online tool for distributed team members and on the Physical board as an Information Radiator. Do a check-in on the retrospective action items and see if they are completed.  Retrospective items can be added to the team’s backlog and be accepted by the team’s PO.

Just collecting feedback and forgetting about the retrospectives is what makes most people discouraged from holding retrospectives.  When people feel that no action is taken and nothing changes, they wonder why they should keep on wasting time with this retrospective exercise.

Participation from all team members is key.  Especially if you have some very quiet team members and others who have a lot of ideas and take over the meeting. Good facilitation skills come in handy to address this concern. If the facilitator knows that some team members will not jump in and be part of the conversation, they can ask direct questions to engage those team members so that everyone is heard and valued.

Lastly, no team is so high performing that they cannot retrospect or find anything else to improve.  They might have found other mechanisms of inspecting what they are doing and how to adjust, that they do not wait until the end of the sprint for this formal retrospective session.  These teams have learned that improvement is always something to look forward to.

We’ve all heard something about Documentation in Agile. I know I’ve heard some pretty extreme comments like “there is no documentation”. Well I’m here to set the record straight.

Let’s start by taking a look at the Agile Manifesto:

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

As you can see it isn’t that there is no documentation, but rather we favor the delivery of “working software over comprehensive documentation”. So what does that mean, and why did I emphasize the word comprehensive?

If you are fairly new to working on software projects, you may not remember the days of huge requirements documents like I do. Projects started out with a group of analysts working together to create a requirements package over the course of several months. We would engage with the customer, run workshops, and watch what users did. We’d end up with one or more three-ring-binders full of documents. There would be statements like “the system must….” and “the system should….” We would give each line item a priority (High, Medium, and Low typically). Then we would create as-is process flows, to-be process flows, context diagrams, data flow diagrams, object models, and state transition diagrams to name a few. Each set of requirements were presented to and signed-off by the main stakeholders; and that may have been the last our stakeholders heard from the team until the software was ready for user testing. At the end of the project, the documents would end up on a shelf somewhere eventually being shipped off to long term storage, never to be seen again.

The Manifesto reminds us that no matter how much documentation we create, if we don’t produce working software, then we aren’t creating value for our stakeholders. It also reminds us to evaluate the documentation we do decide to create in order to ensure it is of value for the project.

The perceived lack of documentation in Agile environments isn’t just because of the manifesto, it is because everything we do is slightly different in Agile compared to a waterfall approach. We no longer create a load of requirements and toss them over the wall hoping the team will understand them enough to create a design document and code. Instead, we work together throughout each sprint to ensure we are creating value together by delivering working software together where everyone has complete understanding of user stories, and everyone is on the same page regarding the design as it emerges sprint by sprint. When specific documentation like Release Notes, or User Guides are required a user story is an acceptable way to track these documentation needs.

As the team discusses user stories in grooming sessions, the goal is to have each story fully understood by the team. The team may suggest other stories, or identify other items they need. The Product Owner and Scrum Master can work together to obtain documentation that is needed by the team to better understand the story. The team adds notes to the story to track decisions and comments that are made  keeping story documentation with the story. So what else might the team need? When working with a user interface, the team will likely need a wireframe or mock-up of the user interface. The team may also want an object model or database diagram. I’ve even known one developer that requested a State Diagram. Unfortunately, there is no single correct answer. The team or Product Owner, may need to engage with other teams (System, Database, or DevOps) to get the desired documentation ready for the team. For a great article on best practices in Lean/Agile documentation check out this article http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm

The three main artifacts in Scrum are the Product Backlog, User Stories, and Test Results. The Product Owner holds the key to understanding stakeholder needs. Should other documentation be required from a stakeholder or compliance perspective, a story in the backlog is a great way to address this need. Also as development occurs, the team needs to ensure that system decisions and their code are sufficiently documented so those supporting ,or enhancing the system in the future will be able to do so adequately. Consider including something in the Definition of Done (DoD) to ensure stories meet these non-functional needs.

Yes, documentation does exist when following an Agile Framework. However, we don’t create a document for the sake of saying we’ve done it. Make a conscious decision of what will be created, and what the intended use is. This way, you won’t have a library of out of date, never to be viewed again documentation.

Face to Face is the best method of communication and that’s the method that Agile promotes.  The benefits of Co-located teams are numerous-  streamlines product development, promotes trust , accelerates communication among the team members, provides opportunities to collaborate, promotes reliability, fosters closer working relationship and the list of benefits can go on and on…..

Teams should co-locate as often as possible, because of the benefits of Osmotic communication.  Osmotic communication was coined by Alistair Cockburn, one of the originators of Agile.  “Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work”.

But in reality, not many of us have the luxury of working with our entire team in a single location. For most of the organizations I work with, the teams are all over the world. Many of these teams work with team members not only in different locations but sometimes in different continents.

So how do these Agile teams communicate and work with each other effectively?

Here are some simple ways to engage the entire team and not let any team members go in dark:

• Establish team core hours for facilitated discussions and working sessions. The team can establish a certain time of day when the entire team is available for group discussions: talk about the backlog, have design reviews or delayed discussions on any topic and dedicate that hour or two hours just for the team. The team members can be available on tools like Skype, or phone, and they can work on different things if the team doesn’t have any discussion items for the day. The idea is to have all team members available and ready to talk as if they are in the same room.

• Establish Team norms or working agreements. The team must decide on rules for working together and communicating with each other and these rules or working agreements should be followed by all team members and fair to all team members.  So for example, don’t have meetings that require one group in a certain time-zone to always be the ones to get up early or stay late.  Switch it around and make it fair.  Include things like phone etiquette in your norms.

• Utilize the Scrum of Scrum technique. A technique to scale Scrum up for large groups, consisting of dividing the groups into Agile teams of 5-10. Each daily scrum within a sub-team ends by designating one member as “ambassador” to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums. This same technique can be used when the team members are across continents and time zones and therefore cannot be available for Daily team ceremonies.  Each holds their own daily Scrum and then participates in a Scrum of Scums later on.

• Involve the entire team for Ceremonies. As much as possible, always involve all locations for ceremonies, such as Sprint planning, review, retrospectives, and daily stand-ups. Daily stand-ups or handoffs between remote teams bridge communications and establish a framework for frequent synchronization and collaboration.  If you have access to video conferencing, great!  If not cheap portable cameras attached to a chair and a laptop make a great improvisation.

• Rotate members around – cross pollinate. Rotate team members between various locations, this might be expensive but leads to a cross trained and fungible team. Even sending one person from each location to work with other groups will help build stronger working relationships and create cultural understanding.

• Use On-line collaboration tools. In the absence of co-location, teams will have to rely heavily on automated tools for collaboration and to create a single repository that keeps the efforts of the teams in full view for all team members.  The osmotic communication flow can be somewhat replicated for the distributed team using the virtual tools such as IM, Skype, Webex, and other on-line collaborative tools.

At  a team-level, use automated tools like Jira, Planbox, LeanKit, other shareware or low-cost options to maintain synchronization and visibility into work.  At the cross-team or program level, tools like Version One, Rally, other enterprise-level options can be used.

• Use a common document repository (ex. Sharepoint, Knowledgelink) for sharing information.
• Develop a shared team vocabulary and a team website
• Hold in person team meetings at regular cadence. Team members should meet others in person at regular intervals. While sometimes costly, this investment is worthwhile. People are the most important part of the team, they work really well together when they know and understand the person they work with just not a name. So setting up a regular cadence of team members meeting face to face helps improve the distributed team dynamics.
• Establish Clear Sprint goals and expectations. The team members should have clarity on the work they have to complete to meet the team’s objectives. Daily Scrums can be used by the team members to be mutually accountable and to set clear expectations for each other.
• Over communicate – When the team members are distributed sending in a quick summary of the discussions makes sure that everyone is on the same page.
• Be knowledgeable and respectful of the different cultures making up your distributed teams, such as holidays and working hours.

Lastly: Be patient.

If the team members are in different time zones being respectful and cognizant of the time difference is extremely helpful. Unless a decision needs to be made immediately, the team members should be given time to respond because they might be working on a different schedule or in a different time zone.

I’ve been working with large organizations where team members are in multiple locations quite a bit lately. This environment can be challenging, especially in ensuring everyone is engaged and not multitasking during Sprint Events. While there are a number of things I’ve covered in my blog “The Reality of Distributed Teams”, here are 4 specific things you can do to help build better agility with your remote teams.

1. Encourage team members in similar locations to meet in a room, and not just “dial-in” from their desk.

• Builds team continuity
• Reduces the urge to multi-task
• Follows the Agile Principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

2. Follow Sprint Event Agendas

• Ensures the team keeps on task and is not sidetracked
• Ensures we have a clear outcome to strive to for each event
• Keep to a time-box, and don’t create extra meetings to make up for not reaching the desired outcome at the end of a prescribed Sprint Event

3. Use a tool like planningpoker.com to size stories

• Simultaneous Pointing – reduce influence by more senior members
• Encourages discussion to get complete understanding of stories
• Supports “team sizing” instead of “individual” sizing

4. Allow for silence

• Creates an opportunity for the team to talk
• Product Owner and Scrum Master should not be doing all the talking, especially during planning. In Sprint Planning or Story Grooming/Refinement once the PO has introduced a new story, turn the meeting over to the team for questions and discussion amongst themselves. If there is awkward silence for a bit, it’s OK. Before moving on, be sure and ask if the team needs more time to discuss.

Whether your team has been together a long time or is just starting out, creating an environment for success by actively addressing remote issues is sure to add value to your team. Give these suggestions a try and let me know your successes!

As I sat watching Sunday Football, and thinking of my upcoming blog… I became aware of the similarities between football and Agile! Consider this, each time my football team has the ball, they have an end goal; to get points on the board. They also have intermediary goals, to deliver 1^st downs in order to retain the ball. They studied the opposition, and made some plans for the game. Then at the beginning of each play, they make a plan in the huddle, and execute. At half-time they have a retrospective.

So if you are into football, ask yourself; what would happen if they had to plan the entire game in advance? What would happen if they couldn’t respond to change within game or even the down? The ability of each player to take responsibility for their work, seeing the big picture, and responding to change as needed keeps the game going. It also parallels what we do when working in Scrum Teams.

Our big picture is provided by the Product Owner. Our end goal to deliver on the big picture incrementally by accomplishing 1^st downs. Sprint Planning allows us to see where we are and identify our plan for the sprint (football’s quarter). Our Daily Scrum allows us to plan the play for a day just like in a football huddle. Based on outcomes, we adapt to change continuing to focus on the end goal.

It takes the entire team to play the game. Each player must be accountable for what they are doing. Otherwise the quarterback gets sacked, the ball is fumbled, and overall play is stymied. There is total visibility. No one can hide if they don’t deliver. Sound familiar. It should. If it doesn’t, than your team may not be transparent about its work.

The Product Owner is like the Quarterback, supplying the team with user stories for the sprint. The Scrum Master is like the Coach, supplying support from the sidelines.

So when it comes to adapting to change vs following a plan, think about that football team you watch on Sunday night.  First, embrace the fact that being Agile allows us to adapt to change and that adaption is what helps us win the game. Second, make sure you make the most out of the huddle, or Daily Scrum, by truly planning how to move the ball, or story, down the field.  Finally, hold the team accountable while you drive to the end goal.  No football team ever wins on the basis of one player alone.

As coaches, we help teams grow and mature.  Mature, effective teams understand each other – who they are, what they’re good at, what they’re not, what makes them laugh, what makes them cry, how they think, their intentions, their hopes, and their fears.

In my last blog, I talked about the Johari Window as a simple and intuitive model which can help increase self-awareness, and improve communication and interpersonal relationships.  It provides a way to visualize and understand how and in what ways we interact with ourselves and with others.

The Johari Window of a new team looks like Figure 1 on the left below, with a small Open area (public self) because team members haven’t had a chance to share much about themselves.

The Johari Window of a maturing team looks like Figure 2 on the right above, with an expanded Open area.

We can help a team go from a profile like the one on the left to a profile like the one on the right by providing opportunities and encouraging team members to engage in:

• Sharing information about themselves – expanding their Open area vertically and a reducing their Hidden area
• Giving feedback to each other – expanding their Open area horizontally and reducing their Blind area
• Discovering new information about themselves – expanding their Open area diagonally, and reducing their Unknown area

One place we can encourage that level of communication and interaction is in a team retrospective.

Introspective Retrospectives

I think of team retrospectives as 2 general types – those that focus on how we did our work, and those that focus on how we work together.

The first type centers on the process of doing work and how the team can improve their process.  The second type explicitly focuses on interactions and communications and how the team can improve the way they work together.  I call this second type an “introspective”.

As teams mature, these two types evolve into one, because the team will naturally begin to incorporate discussions about interactions and relationships as needed.  But for new teams, or teams with low trust, dedicated introspectives can often help them improve their interactions and team climate.

Opening the Window….with the Lens of Understanding

There are many tools, activities, and techniques that can be used to help a team expand their Open area.  A favorite of mine is to conduct an introspective using the “Lens of Understanding”.

As shown in Figure 3, the Lens of Understanding is a 4-quadrant model developed by Dr Rick Brinkman and Dr Rick Kirschner as a way to help understand behavior and what drives it.

In this model, the vertical axis indicates the focus of attention – is it on the TASK or on PEOPLE.  The horizontal axis indicates level of assertiveness – is it PASSIVE or AGGRESSIVE.

The premise behind this model is that people behave based on their intent.  By understanding the intents that drive behavior, we can better understand our own behavior and that of others.

In Figure 4, the Lens of Understanding describes four intents that shape behavior:

Get it done – if our focus is on getting something done, we tend to speed up vs slow down, act vs deliberate, and assert vs withdraw.

Get it right – if our focus is on getting it right, we tend to slow things down in order to see details.  We become absorbed in the task at hand and will likely deliberate before taking any sudden actions.

Get along – when we want everyone to get along, we tend to be less assertive as we put their needs above our own.

Get appreciated – when we want to get appreciation from people, we tend to be more assertive in order to be seen, heard, and recognized.

We all have the ability to change where we’re coming from (our intent) based on the context of any given situation.  And we each also have a “normal” zone, where we’re most comfortable and exhibit our best behavior.

As our intent changes, so does our behavior.  And when stressed, our normal zone behaviors can become exaggerated, as shown in Figure 5.

For example, let’s say in a particular situation, my intent is to “get it done”, and your intent is to “get it right”.  Our intents are at odds with each other, and if we don’t recognize that, or can’t find some middle ground, our stress increases.  In this example, my behavior would go toward Controlling, and yours toward Perfectionist.

Being aware of and understanding the intent behind behavior can help us understand and deal with different behaviors.

Using the Lens of Understanding

Below is a description of a retrospective designed around the “Lens of Understanding”.

Purpose:

• Provide a structured opportunity for team members to tell others about themselves, learn how others see them, and generate insights about themselves and others.

Objectives:

• Increase self-awareness of individual behavior
• Increase awareness about others’ behavior
• Expand Open area of each individual and the team as a whole

Supplies:

• Printed copies of the Lens of Understanding matrix (figure 3 above); two copies for each person
• Small stickies, pens, markers
• Masking tape
• Table set-up to accommodate work as individuals and pairs/quads, plus space to roam the room

Open the retrospective meeting

• Open with the check-in, temperature reading, and/or centering activity of your choice

Run the Activity

• Set-up
  • Hand out 2 copies of the matrix to each individual; ask them to put their name on each copy
  • Each person keep one copy on the table in front of them, and tape the other copy to their back (they’ll need to do this for each otherJ).
  • Facilitator draw the basic matrix (Figure 3) on the board and explain what the two axis’ represent
• Self-assess data
  • Do this part individually and without showing work to others
  • Each person put a mark on their copy of the matrix (the one in front of them) where they think they fall
  • For example, mark what quadrant they fall into based on whether they’re generally task oriented, or people oriented; and whether they’re generally passive, or aggressive)
  • If they have trouble, it might help to think about a specific work example
  • When they’re done, have them turn their copy over on the table in front of them
  • NOTE – this can also be done using stickies vs using a marker
• Feedback data
  • Everyone roam around the room and on the copy of the matrix on each person’s back, place a mark where they think that person is coming from (based on their observations and experiences with each individual)
  • This part may be lively, but ask them to do this without telling each individual where they’re putting their marks
  • Everyone take their seats when they’re done
• Introduce additional information about the Lens Of Understanding
  • Draw Figures 4 on the board; explain about the four general intents
  • Draw Figure 5 on the board; explain how stress can cause exaggerated behaviors
  • Each person take a few minutes to look at their two copies – how they see themselves vs how others have indicated they see them
• Discuss learnings in small pairs/quads
  • Form pairs or groups of four
  • Discuss insights and learnings with others in their pairs/quads
• Debrief at the group level
  • aha’s, surprises, shocks, puzzles
  • One thing they learned about themselves
  • One thing they learned about someone else
  • What will change for you on Monday?

Close the retrospective meeting

• Close with the closing/centering activity of your choice

Continuing the Journey

Developing self-awareness and mutual understanding within a team is an on-going journey.  Using the Johari Window model, along with thoughtful inclusion of activities like the Lens of Understanding, to help develop a team’s Open area will increase trust and create happier, more collaborative, productive, and successful teams.

Send me your comments…..I’d love to hear what you think and your questions, and your experiences, and ideas for helping teams grow.

Many times I have seen newly formed or new to Agile teams and organizations moving from Scrum and/or Kanban to eventually settling for Scrumban as they mature. As I reflect on these teams that I have worked with, I feel that their ultimate form of Scrumban is probably their own kind of Shu-Ha-Ri progression.

Shu Ha Ri is a Japanese martial art concept, and describes the stages of learning to mastery.

Shu – the student copies the teacher’s moves as perfectly as possible. The teacher corrects the student if the movement is imperfect, inefficient, or ineffectively performed.

Ha – In this stage, the student understands the principles well enough to depart from rigid practices. The student experiments and makes observations of the new techniques. The newly emerged techniques become his own.

Ri – stage, the student has reached a point of mastery and is able to teach and to adapt to new situations easily.

Shu – the journey begins
Teams and organizations new to Agile and in infant stages of Agile transformation start off as being Scrum .They start following all the Scrum practices, conforming to the roles of the Scrum and they kind of follow the prescriptive form of Agile, or Scrum which makes sense. Installing a basic set of proven Agile practices by force can start yielding quick benefits for the organizations, letting them see how the new methodology leads to working faster and delivering the value out to the customer quicker. It kind of builds confidence at the team level too. The teams and the organization are both at the Shu level.

The team keeps having the daily scrums, planning sessions, locking the sprint, reviews and retrospectives in a prescribed manner till it becomes muscle memory.

When a team produces consistent results using rigid methods, they have completed their Shu stage.

As an Organization, these successful practices are also replicated to other areas to see the benefits in the other parts of organization.

Ha – adjusting the sails
With each retrospective and in the spirit of constant improvement, they change the practices to what make sense for their own unique solution. Teams start to feel maybe Scrum isn’t the right way for what they are doing.

Some teams don’t want to be restricted by the lock down of sprint commitment and want to be able to pull their work. Some of the teams want to move away from the planning session or role demarcation but still like the way certain things worked in Scrum and start to work on what is the “Ha’ phase. In the Ha stage, teams often will start to innovate their processes and the way they design their software. They may adopt new methods and tools in dealing with each other. Retrospectives are the key in the Ha stage to gauge the effect of the newly formed processes: are they helping the team or taking them back into the post Scrum era.

The Ha stage will include some successes and some failures, but it will be a learning experiment and the team will be wiser and mature with each of these experiments.

As an Organization starts doing Scrum in various teams and divisions, it becomes clear that one size doesn’t work for all aspects of the software development, and some prescriptive processes which work for majority of teams clearly need more refinement or customization to work for the other teams. This is the organization getting into the ‘HA’ phase. This can be extremely useful for existing Scrum teams looking to improve their scale or capability.

What the discovery leads to is Scrumban, an Agile management methodology that is hybrid of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban.

Scrumban is a pull-based system, where the team no longer plans out the work that is committed to during the planning, instead continuously grooming the backlog. The same Scrum meetings (planning, review, and retrospective) can still take place, but the cadence of them can be more context-driven. The main emphasis is on limiting the work in progress (WIP).

With Scrumban, a team benefits from the prescriptive nature of Scrum while the process improvement of Kanban allows their process capability to continuously improve (kaizen) , reducing the waste and simplifying the way they work. In all of this they develop something new and unique to the team and hence get to the “Ri’ stage.

Ri – losing sight of the shore
At the Ri stage of an Agile transition, the team becomes capable of abandoning rules and strict forms while increasing the productivity and customer experience. They can produce quality work, with the rule or methodology of their own.

As an Organization, it might be a new flavor of Methodology which works best for the company itself.

Before I get to how much capacity there is in a sprint, let’s take a look at the flow. If you are doing Scrum, you are probably familiar with a diagram that looks something like this:

When it comes to figuring out what day to start on, and when each ceremony should be done, I thought it would be nice to see it all laid out and explained in a calendar format. Here is my calendar view (there are others) of the ceremonies for 2-week sprints.

No matter what numerical day of the month it is, I recommend starting sprints on Wednesday or Thursday. The reason is simple: it is easier to get everyone to attend Sprint Planning, Sprint Review and Sprint Retrospectives when they don’t fall on Monday and Friday’s. If you are experiencing difficulty in attendance to these ceremonies when they are on Monday’s and Friday’s, consider moving the first day of the sprint to Wednesday or Thursday. With continuous delivery, you can promote code to production on Thursday, rather than on Friday. Thursday promotions to production allow first day support to happen on Friday, rather than the weekend!

Day 1 – Sprint Planning – The Product Owner has the stories prioritized for the upcoming sprint all ready and presents them to the team. The team will size (if not already sized), discuss the design and tasks for the stories, and commit to what they can get done. Allow adequate time for the team to work together to complete tasking and commit to the work.

Day 6 – Grooming – While the Product Owner is always refining stories and getting them ready for the team, they must also meet with the team on a regular basis to get their input into upcoming stories. During the grooming meeting the team can let the Product Owner know what additional information might be needed to consider the story ready for a sprint. If there is enough information for the team to size stories, this is a great time to do so.

Day 9 – All Code in QA Environment – I know this isn’t a ceremony, but it is worth pointing out. Stories should be between ½ day – 2 days of work, this means that stories are flowing into QA throughout the sprint. By Day 9, if you have a lot of code still in process, how will it be tested in time for the Sprint Review on Day 10? Developers can be busy doing fixes, code documentation, refactoring, or helping test each other’s code to ensure everything is ready for the demo portion of the Sprint Review.

 Day 10 – Review & Retrospective – Typically 1 hour for each ceremony. Remember that the Retrospective is reserved for team members only.

Day 2 – 10 Daily Scrum – Keep this ceremony short and sweet allowing just 15 minutes for the team to check in with each other. Answering the 3 questions, is to help them plan. It isn’t a status meeting.

For more on the ceremonies, go right to the source here http://www.scrumguides.org/

Calculating Sprint Capacity
I use this calendar to show the flow, plan for the meetings, and to identify my teams’ capacity for the sprint. How many hours does your team actually get to code in a sprint?

Typical Day – Considered to be 6 hours at most organizations based on an 8 hour day with 2 hours of email, admin and other meetings.

Days in a Sprint – 10 (if there aren’t any bank holidays or vacations) = 60 hrs per person, per sprint

Sprint Ceremony Allocation – Planning (4), Scrums (9 x .25), Review (1), Retrospective (1), Grooming (1) = 9.25 hrs per person, per sprint

Average Capacity per person = 50.75 hours (60 – 9.25 hrs)

This can be adjusted to suit your ceremony timings, and for holidays and vacations. (Hint: For a 3 day weekend reduce capacity by just 5.75 hours as everything else has already been deducted.)

Why is capacity important?
A team’s commitment may not be to last sprints velocity, if their capacity is reduced. It is good to understand the impact of holidays and vacations on velocity as a result of reduced capacity. Is this a surprise? Let me know. I’m always interested in your comments and feedback. Happy Planning!

As Agile Coaches, we help teams grow and mature. But there’s no how-to manual that tells us how to do that.  So how do we accomplish it?

Today I’ll talk about a model I find useful when working with teams. The “Johari Window” model was developed by Joseph Luft and Harry Ingham in the 1950’s from their work with groups.  “Johari” comes from a mash-up of “Joe” and “Harry.

What is it?
The Johari Window is a simple model, a tool that can help build trust and improve interpersonal relationships within a group by increasing self-awareness and mutual understanding, and improving communications.

Johari’s Window has 4 quadrants:

OPEN
The public self or open persona.

This quadrant represents what you know about yourself that others also know about you (includes behavior, knowledge, skills, attitudes, strengths, weaknesses, etc).  This is the self we share with others.

BLIND
The blind self or naïve persona.

The blind area represents what is known by others, but you are unaware or don’t know about.  We can’t access the positive things in this area because we don’t know about them, and negative aspects that we don’t know about make us vulnerable.

HIDDEN
The private self or secret persona.

This quadrant presents what you know about yourself, but keep hidden from others.  These are the things that make us uncomfortable or that we’re not confident in.

UNKNOWN
The undiscovered self or mysterious persona.

The unknown area represents what is unknown by you and unknown by others.  This dark area is where our deepest fears and buried talents reside.

The model is based on two fundamental concepts:

• Trust and growth can result from being open
• Awareness and self-development can result from asking for feedback

 How is it used?
Johari’s Window can be used from an individual, team, work group, or project perspective.  The ultimate goal is to increase the “open” quadrant….expanding the public self, and reducing the hidden, blind, and unknown areas.

Opening this window is accomplished by:

• Telling others about yourself…..willingly sharing your thoughts and intentions. The more people know about us – how we think, what’s important to us, how we make decisions – the more cooperatively, collaboratively, and effectively we work together.  The sharing here refers to things that are appropriate for the environment, e.g., sharing intimate details isn’t appropriate at work, and would not have a positive effect on relationships in this setting.
• Asking others for honest feedback….on how they experience you and what impact your behavior etc has on them. Be open to receiving feedback, as it’s a way for us to learn what others see but we don’t, highlighting opportunities for growth.

It’s important to acknowledge here that the word feedback has a negative connotation in American culture.  That’s because feedback is usually couched as “friendly advice” about what we’re doing wrong, or delivered in a context of judgement and intimidation, e.g., “you’re wrong/broken, and you need to fix this or else”.  So we fear it.

But feedback is really about the person giving it, not about the person receiving it.  Most of us have good intentions; we do what we think is right, for the right reasons, and are unaware that others might receive it differently than we intended.  Feedback isn’t about us being wrong or broken, but rather a way for others to tell us our impact on them.  It is a gift….ours to do with what we want.

• Introspecting regularly….regularly looking inside, honestly assessing what we want, how we behave, what we have to offer, what we need to develop, and increasing our self-awareness.
• Challenging ourselves….take more risks, expand boundaries, solve bigger problems, work with different people, or execute on a bigger stage. This will tap into and reveal our deepest fears and help us discover unknown strengths.

So what do I do next?
Whether you’re using the Johari Window model for as an individual or for a team, the key is the more developed the “open” area is, the more comfortable, happy, successful, and collaborative we’re likely to be.

Stay tuned for my next installment where I’ll talk about crafting a team retrospective using concepts around the Johari Window.

Send me your comments…..I’d love to hear your questions, experiences, and ideas for helping teams grow.

Welcome to the final part of my 12 Principles series where we’ll cover the final 4 Agile Principles. (In case you missed it, here’s a link to Part 1 and Part 2). If you utilize all three parts together, you will have a great resource for working with your teams’ Agile growth.

9. Continuous attention to technical excellence and good design enhances agility.  
We may be working in short sprints, but this is not an excuse to let technical excellence slip. Potentially deliverable means the code is tested and passes.

Technical debt is dealt with on a regular basis, and not left until the very end of the project.

This isn’t one and done, so support your teams to be the best they can be. Allocate approximately 20% of each sprint to “technical excellence” https://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).aspx. Some basic things you should be doing are planning for Test Driven Development (TDD), pairing and refactoring. Developers create simple designs, and look for constant improvement through regular feedback.

One final thought, Technical Excellence is about more than developer’s code. It is also about the organization becoming more Agile. Think about working with all members of the organization to improve their skills by cross pollinating, training, and mentoring.

10. Simplicity–the art of maximizing the amount of work not done–is essential.
 The phrase to remember is not to “gold-plate” your features. One best practice here is to follow TDD. By developing to the story and its acceptance criteria until the test passes, and no more.

Some developers may feel they could do more, but what if what they create won’t be used? Then we have wasted time, and a potentially untested item. It’s great to have ideas, so write a story and pass it to the Product Owner for prioritization in the backlog. Remember it’s easier to create complicated solutions, harder to create simple solutions… but simple solutions last longer, increasing quality and decreasing total cost of ownership.

11. The best architectures, requirements, and designs emerge from self-organizing teams.
Change can be difficult, and moving from a waterfall environment to an Agile environment is no exception. In order for team members to identify the best design during Sprint Planning, they must be knowledgeable about the environment and system they are creating. This means we can’t treat them like mushrooms (keeping them in the dark, and feeding them “fertilizer”).

If your organization is working with complex systems, ensure the architectural runway is in place. Expect some ramp-up time for team members to become familiar with the environment. Ensure that there are resources assigned from the “systems” team to support each scrum team. Create domain models, physical models, etc. as needed to ensure sufficient information is available to the team. Then allow sufficient time for the team to discuss and build on their designs during Sprint Planning.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Welcome to the Retrospective! Agile is an empirical process. Based on the results, we adapt and improve. When I hear that teams are struggling with retrospectives, I suggest they rethink how they think about this ceremony. It isn’t a gripe session. It is an honest introspection of our performance.

Following this principle means we need to take a look at how we are doing, and commit to experiment to create small improvements. Each and every sprint allows us to try something out, and to look at the results at the end. If the results are positive, great. We can decide to run with the change. If the result isn’t positive, we can choose a different approach for the next sprint. There are great resources out there to keep Retrospectives from becoming dull and boring. If you are struggling, take a look at the book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen.

It is easy for an organization to be “Scrum-but”. The risk in staying “Scrum-but” is not truly getting all the benefits of being Agile. Read all three parts of this blog and evaluate how your organization is doing. I invite you to add your comments and experiences, as we share in the Agile Community any ideas for continuous improvement!

 “How much scrum would a Scrum Master master,
If a Scrum Master could master scrum?
He would master, he would, as much as he could,
And master as much as a Scrum Master would.
If a Scrum Master could master scrum.”   —-Cindy Bloomer

When recently meeting with a client a very interesting question came up: How many teams should a Scrum Master Scrum? They had been hearing that a Scrum Master’s role is just a facilitator role and all the Scrum Master has to do is run the ceremonies, so a person in the role should be able to run 2-3 teams without any issue. Therefore a novice Scrum Master should just be Scrumming one team, an experienced Scrum Master can safely handle up to 2-3 teams and a very experienced Scrum Master can handle more than 3 teams.

In my opinion, the experience of the Scrum Master does not translate well into the number of teams they can handle. Although it is a factor, in all honesty, there are a number of factors that influence the decision, such as organizational maturity, team maturity, project type, the value of the project, and the effectiveness of the Scrum Master role.

Is the Scrum Master just a facilitator? If so, then yes, the Scrum Master can be over 2-3 teams.
Because then the expectations are just to run the ceremonies and make sure teams are running well, are working towards the objectives set in PIs, and are meeting the sprint objectives. And even for this scenario, the team needs to be a mature team. A team that has been together for at least 6-8 months has worked through the forming, norming, storming, and are now in the performing phase and no one on the team is very role specified. They believe that they have to accomplish stuff as a team.

It also depends on the Organization’s Agile Maturity. If the organization has just started the Agile Transformation journey and has yet to establish Scrum Practices, then the Scrum Master should just be dedicated to one team.  This is because they will have many impediments to resolve, and they will need to help team members understand and see the value in Agile practices. Helping a newly formed team adopt Agile practices will be a full-time job for the Scrum Master.

With all that said, I believe there are many factors that help determine the “best” number of teams for a Scrum Master to handle; the experience of the Scrum Master is just one of these factors. I have seen many experienced Scrum masters running just one team and declining to work on multiple teams at a time. Although I agree in some organizations Scrum Masters don’t have a choice – the number of teams a Scrum Master handles is a key differentiator in performance, both team performance and Scrum Master Performance.

I want to hear about your thoughts and experiences with the effectiveness and the Scrum Master role when it comes to scrumming multiple teams…

Over the course of this three-part blog series, I will cover all of the 12 Principles. In this second installment I hope I’ve peeked your curiosity. As I said in Part-1, I believe following these principles is the core of being “Agile”.  Is your organization embracing the fundamental principles of Agile? Are you open to culture change?

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 

OK, we’ve hired good people, who want to do a good job. Now we just have to show them we believe in them. If it were only that easy. Too many times fear drives an organization. Too many project failures, a culture of distrust, or simply a mindset of “this is how we’ve always done it” leads to micromanaging and difficulty in enabling teams to take ownership of their work.

I’ve personally been a part of many organizations who falter when trying to motivate teams. Or, even worse they totally fail in the trust arena. Is it scary to start moving away from micromanaging and micro-reporting? I’m sure it is. With Agile we have built in controls to help us manage teams at “arms-length”. We can listen in on Daily Scrums, and must attend the Sprint Review to see the teams’ sprint accomplishments and provide feedback. Yes, a team may “fail”, but what have you lost? In a two week sprint, you may have lost a little time. Do you think the team will have learned from the Sprint? Will they try harder to succeed next time? Is a two week loss better than a year of micro-managing and still not getting the desired results? You bet!

Organizations need to ensure the teams are supported appropriately with dedicated team members, regular involvement by the business, access to information, and ownership of delivery. Motivate the team with small rewards and acknowledgement of successes, and watch them deliver!

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation 

Most of us recognize that when we are together face-to-face communication flows. Spontaneous questions are raised, and connections are made.

This principle may not be so easy to follow if the teams are not collocated. Put a little extra effort into the use of technology to emulate face-to-face communication whenever possible. Team members will form stronger bonds. The benefits include stronger and more motivated teams, as well as reducing risk of miscommunication including errors regarding the intent of user stories and acceptance criteria.

Lead by example, and allow introverts to have their privacy, but don’t miss this opportunity to build team that becomes highly performing.

 7. Working software is the primary measure of progress 

I was once told “watch the runner, not the baton”. Too many times, organizations focus on hours worked (or sat in the office), rather than actual outputs. This principle reminds us that what we really want to watch is the outcome.

Agile measures velocity of the teams’ completed work. If a team is struggling to meet their commitment, then look at root causes. It is likely there are other issues that need to be addressed. Are the user stories actually “ready” to be accepted into the sprint? Is someone trying to get the team to commit to more work than they can deliver? Start with small steps and build on successes. It is a success when the team delivers what they commit to. Then ask the team to identify process or people improvements during their retrospective to help grow velocity.

Place your emphasis on seeing quality deliverables at Sprint Reviews, not on how long the team works, or how busy they look.

 8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

We’ve all had those moments where we feel staying just a little bit late at work, or skipping lunch will help us meet our deliverables. After all, it’s just “this time”… if only that were true! Instead, working late and skipping lunches becomes a habit. Next thing you know, it isn’t just one team member; it’s the majority of the team. While some leaders jump for joy, there are repercussions.

Even outside of software development workers engaged for more than 50 hours a week open themselves up for health issues, and may not actually be as productive as they would working a standard week. See http://www.cnbc.com/2015/01/26/working-more-than-50-hours-makes-you-less-productive.html

 When it comes to software, the idea of working at a sustainable pace originates in XP practices. Over time implementation of all the principles enable us to create an environment where all teams can work at a sustainable pace. See http://www.langrsoft.com/articles/sustainablePace.shtml

 Work-life Balance isn’t just a cliché. Put working at a sustainable pace into practice, and watch the results.

With just one more installment left, I look forward to your comments. Let me know how your organization incorporates the Agile Principles into their culture, or struggles you face in following Agile Principles.

Over the course of this three part blog, I will cover all of the 12 Agile Principles. In this first installment I implore you to stay tuned for all 12, and get to know how principles can impact your team. I believe following these principles is the core of being “Agile”.  It is a topic I am always excited to discuss. How does your group follow the 12 Principles? Is there room for improvement?

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 
Let’s face it, if we aren’t delivering something of value, what are we doing?

Everyone on the team must understand the value of what they are delivering. As a team, we become “one” focused on our delivery. The value we provide binds us together, and gives us purpose.

Product Owners can provide the team with a Vision to help guide the team to value delivery. Each sprint delivery supports the vision.

We aren’t all lucky enough to work on feature teams delivering software. If you fall in this category, just replace the word “software” with what you do deliver.

Find your value, and deliver small pieces like building blocks.

2. Welcome changing requirements, even late in development. Agile processes harness change for customer’s competitive advantage. 
While this principle seems to invite disastrous changing of scope at any time, this is not the intent. We do not interrupt sprints once they are started, unless it is a dire emergency. There are ways to stop a sprint, which is a topic on its own. What this principle asks us to do, is keep our backlog up-to-date.

If a new feature is requested, it can easily be added to the backlog. If a feature in the backlog is considered to be out-of-date, it can be removed or updated.

As development progress, and more of the backlog is completed, everyone is learning and discovering together. This principle allows us to change, reminding us that the backlog is fluid.

Organizations need to adapt their policies to embrace these changes, or they miss out on a fundamental benefit of being Agile.

Teams should not feel mad, angry or bad because requirements have changed. I often see negative reactions to change, when just the opposite should happen. Through the teams’ continuous delivery, we learn and therefore we adapt.

I like to tell leadership, through your Product Owner we enable the team to build the highest value features at any time. Don’t get locked into years of work in the backlog. Stay engaged, work with Product Owner, keep the backlog alive. Remember the motto “just enough, just in time”, as it will reduce waste by not documenting requirements too far out in the future, that could end-up being changed, or cut altogether.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. 
You’ve decided to follow Agile. You have a backlog, and a team ready to work. Now you just have to get everyone focused on frequent delivery. Organizations like Netflix deliver continuously (see http://venturebeat.com/2014/03/10/continuous-delivery/). However, the rest of us may be still trying to adapt to delivering at the end of a 2-week sprint.

The reason for short time scales is important to understand. Short time scales reduce risk and waste. We test smaller chunks, we get feedback sooner, and overall can react to change easily when we are working in small increments. A short sprint cycle provides plenty of practice, and opportunities for skill and process improvements.

The team needs small stories. Without stories small enough to be built and tested during the sprint, the team will not be able to fit work into shorter time scales. How small? Half a day to two days of effort. Do you shudder at the thought? Developers don’t always like this concept at first, but it is important to try smaller pieces of work. The benefit of small stories outweigh the fact that developers may have to touch code more than once.

Many Agile organizations aim for two week sprints. Some successfully, but new Agile organization may allow teams to work on just a couple of stories that take the entire two weeks; when complete, these stories may be handed over to a QA team. If you are falling into the latter category, there is still improvements to be done to truly benefit from Agile.

In the Scaled Agile Framework, we are introduced to the phrase “Develop on Cadence, and Release on Demand” http://scaledagileframework.com/develop-on-cadence-release-on-demand/. Supporting the notion that the teams’ developed work may sit until the organization is ready for the release, although it is considered “delivered” by the team. Delivery by the team, means the work passed test and is done. Completed work is ready for Sprint Review. The work is demonstrated and feedback is gathered.

4. Business people and developers must work together daily throughout the project.
Oh how I long to click my heels together, and be transported wherever I want. As an Agile organization, you are lucky if everyone is collocated. It is a desire many of us share. The reality is Agile has moved beyond start-ups and web-dev groups. Agile is embraced by organizations large and small; located centrally as well as all over the world.

Using good communication tools can help us feel like we work together, even when we aren’t collocated. The idea of working together daily, allows everyone involved to participate in the Daily Scrum; it allows us to have easy access to each other. No longer are requirements written and “thrown over the wall” to be developed. Developers can share their screens with us, ask questions, get feedback, and quickly resolve issues when Product Owners and business users are readily available. Don’t wait until the Sprint Review to touch base with your team. You will find you have another way to reduce risk and waste.

Use Team Agreements or Team Norms to identify practices for working together. Collocate teams whenever possible. Invite business users to Sprint Reviews. Include times when Product Owners will be available to everyone, as well as when developers can work uninterrupted.

Let me know your comments, and stay tuned for Part-2 where I’ll will discuss the next four Principles.

Being a Product Owner is a really hard job. I have been hearing this for a long time and it has come out in almost all of the retrospectives in one way or the other over the years.  Here are a few recurring themes I hear:

Product Owners and decision – making
I often hear things like – “My Product Owner doesn’t make decisions quickly enough or by themselves. It feels like they have to check with their leaders even before making even the most trivial decisions.”

My questions or thoughts revolve around – is it really a person thing, or is it pointing to the management not providing Product Owner the authority to do so? Is it the management’s mandate for the Product Owner to seek approvals before making any decisions?

If that’s the case then not getting the questions answered in timely manner can impact the completion of work and eventually has a significant impact on Time to Market. It is probably how the organization is structured and the organization probably needs to shift from a Do Agile to a Be Agile mode.

Product Owner is not technical
When did the requirement to be a Product Owner become technical?  A Product Owner doesn’t need to be technical. They need to answer the team’s what’s not really the how’s.

Going back to the Agile Principles: The best architectures, requirements, and designs emerge from self-organizing teams.

Product Owners should not be the ones providing teams the technical direction. They should be able to provide the vision to the teams.

Teams are the ones who make the technical decisions around the design and architecture. The entire team and the Product Owner can look into the various design options and discuss the trade-offs but it is the team that is responsible for the how the implementation will take place and how long would it take.

Product Owner is not available to make the decisions
Being a Product Owner is a full time job. A Product Owner should have ample time to sustainably carry out their responsibilities. If the individual is overworked, the team’s progress suffers and the resulting product may be suboptimal.

At a workshop this week many of the Product Owner attendees were overwhelmed with the length and breadth of the Product Owner role.  They said things like, “As a Product Owner should I be making all the decisions?”, and “Are they really a single- wringable Neck…..but why??”

This role is by no means is an easy role. They have to be constantly engaged in conversations with the stakeholders, keeping a check on the pulse of the market, looking at trends and innovation but at the same time be available with the team to answer all the questions.

I feel very strongly about the Product Owner making the decisions – at a team level the Product Owner is expected to make the decisions. They are responsible for providing the answers to the team. Be the single point of query or decision making body for the team. The Product Owners should be available to the team at least for some dedicated team time or core hours every day.

You should be that leader for the team so the Team does not have to look any further.  The Team can just ask questions of you and get an answer and be sure what is required off them to fulfill the commitment that they made during the sprint planning or the PI planning.

But in all honesty is it Team Vs Product Owner….not really
The memories of best teams that I carry in my heart are the ones in which all of us worked together. We were open enough to call out ‘hey, need you for this and that,” or “I need …….this from you,” and “you need to show up for this meeting and be available at this time…”.

The team (onsite and distributed), Scrum Master and Product Owner all were available during core hours and would address things as they came. Does the level/seniority of Product Owner in the organization matter in the quality of decisions they make? Or is it how much confidence and trust their team and leadership places on them?

Before we start to worry if we have the best Product Owner in the whole world, or if we can be the best Product Owner, it’s important to remember that Product Owners, like the rest of the team, need time and support to acquire the necessary skills.

Everyone has their unique strengths and weaknesses and that’s what we bring to the team. A Product Owner might be great at providing the vision for the product, interacting with the team and stakeholders, but may not be the best at writing user stories.  In areas of inexperience or weakness, the team would pitch in, helping with the work and enabling Product Owner growth.

So, ultimately what matters is the ‘We’ as in team not ‘I’ as a Product Owner.

I’m often asked how to create empowered teams.  The question usually includes the exclamation “I told them they’re empowered, but they’re not acting like it”, and an expectation that I’ll be able to provide a successful formula or recipe that can be replicated.  Well, I don’t have a specific formula, but here are some important concepts I’ve learned.

Empowerment is a two-way street
It’s not enough to anoint people or teams as “empowered”, they need an environment that is congruent with empowerment, and they have to accept the mantle of being empowered.

Providing an empowering environment is the responsibility of leadership, top-to-bottom in an organization; accepting the mantle of empowerment is the responsibility of each individual and team.

As individual team-members go, so goes the team
Even in exactly the same environment, different teams will likely exhibit different levels of empowerment, because each individual team members’ level of acceptance is different.  Personal style, culture, history, experience, values, comfort with ambiguity, and risk tolerance all affect an individual’s willingness to “be empowered”, and the extent to which they exercise that empowerment.

While you and I will vary in how we embrace empowerment, we both need the same conditions to be met.  To feel and act empowered, we need:

Clarity – I am clear about what needs to be accomplished (intent), and why it’s important (value), even if the how is uncertain.  I understand the purpose and what success looks like.

Ability – I have the knowledge and skills to do it, even if I don’t have specific experience.

Agency – I have the authority to make decisions about how I do it.

Safety – I feel safe to do it. To make decisions and act; to fail so I can learn; to communicate honestly and openly.

Belief – I believe I can do it. I have self-confidence and self-efficacy.

Interest – I am interested in doing it.

Creating an Empowering Environment
Julian Rappaport, in “Studies of Empowerment” (1984) said “it is easy to define empowerment by its absence, but difficult to define in action as it takes on different forms in different people and contexts.”

Regardless of how it’s accomplished, successful empowering environments satisfy the conditions identified above, and actively encourage and support individuals to grow in these areas.  There are underlying themes that work from one organization to another, including:

• Don’t solve people’s problems – help them learn how to solve their own
• Change the language – thoughtfully replacing key phrases can have a huge impact
• Truly believe in the good intent of others – people don’t set out to do the wrong thing
• Make learning important – not training, although that’s a component, but learning by doing
• Give permission to fail –we learn the most when we’re free to fail
• Provide opportunities to succeed – it builds confidence
• Decisions are choices, accept the consequences of yours – and show others how to do the same
• Be curious – but don’t question, it erodes confidence
• Become story tellers – stories inspire and provide context and clarity
• Set reasonable boundaries – and help others learn to expand them to broaden their sphere of control
• Expect honesty – not compliance
• Walk your talk – be visible and show how it’s done
• Help them learn to walk – challenge people to step outside their comfort zones, and support them

For a story of what Stephen R. Covey calls “the most empowering organization I’ve ever seen”, check out the book Turn This Ship Around by L. David Marquet.

I’d love to hear your thoughts….how do you help create a sense of empowerment?

Sometimes when I have wait time, I pull out my phone and play games.  Nothing sophisticated or too demanding, just something calming that allows my mind to wander.

Last week I flew to DC, and, once seated, found myself waiting for everyone else to board.  So I pulled out my phone and played a round or two of “Swiped”….what can I say, it’s free and I like the bright colors.

As I played, it dawned on me this simple, mindless little game reinforces some big concepts; concepts that influence our behavior and help define our comfort with change:

Perfection slows me down
Trying to optimize each move by swiping all possible jewels takes longer and may result in a lower score.  It’s a tradeoff that needs to be consciously made.  For you, is it more important to finish everything perfectly, or finish enough and move on?

Smaller isn’t exciting, but it adds up
In baseball, hitting a “home run” is exciting and adds to the score quicker.  It also makes for bigger heroes.  Yet looking for that perfect ball allows a lot of balls to go by that are “good enough” to hit and keep the game going.  How ‘bout you….do you go for the small, sure hit, or do you wait for the home-run ball?

The closer I get, the less I see
Perspective makes a difference in situational awareness.  Holding the phone close, or focusing too much, or too early, on a specific move keeps me from seeing other possibilities.  Holding it a little farther away allows me to stay aware of the whole, while still seeing details and possibilities for the next move or two.  What perspective is best for you?

Gold is dazzling, but isn’t necessarily the best move
Those bright and shiny gold gems really draw my eye, sometimes distracting me from seeing different options, and making better choices.  Do you find yourself drawn by the gold?

Sometimes the best move is any move
Start somewhere, deal with what’s in front of you, see what develops, and do the best you can to keep moving forward.  How about you….do you pause to consider options, or do you make quick decisions and move forward?

Send me a comment…I’d love to hear your thoughts!

As an Agile enthusiast, trainer and coach I’m pretty passionate about being Agile regardless of the specific framework being followed. In fact, my passion lies in the culture of being Agile, rather than a dogmatic adherence to a framework.

Following a Framework

A dogmatic approach to a framework may work well if you are a “.com”, start-up, or other application development shop. But, for those of us working with large corporations a dogmatic approach feels impossible. Here are a few of the reasons why:

• Team members are not co-located
• Teams are not developing software
• Team members are not fungible
• Teams cannot deliver anything fully functional at the end of a sprint (1 – 4 weeks)
• Teams rely heavily on other teams to deliver components, and struggle with dependencies
• Organizations have a legacy structure that doesn’t support being Agile
• Organizations want the teams to be Agile, but they don’t want to change anything else

I fully support adopting a framework, so don’t get me wrong. Organizations should try to adopt as much as possible of their chosen framework, and specifically note exceptions acknowledging deviations from a given framework. However, before the organization gets concerned about the framework they are trying to follow, I ask them to look at the Agile Manifesto and Twelve Principles. How much cultural change is the organization willing or able to accept in order to adopt a framework? As true agility requires both, a change to the new framework and a change in culture.

Cultural Change
When the “gurus” got together in Colorado, they not only defined the Scrum Framework, they created the Agile Manifesto, and Twelve Principles. These two items identify the Culture of Agile. To truly be Agile, organizations must work on the cultural change required regardless of the framework.

From the Manifesto:
Does your organization really put Individuals and Interactions over Processes and Tools?

Carte blanche rules for processes and tools don’t always work for everyone within the organization. Some tailoring must be done to truly be effective. Marketing teams may not need to use the same story writing and management tools as Software Teams.

Do they favor Working Software (Value Delivery) or Comprehensive Documentation?

Note: For non-development teams, I prefer to consider what “value” the team is delivering as working software does not apply.

This is not an excuse for skipping documentation all together.

Does your environment allow for true Customer Collaboration over Contract Negotiation?

Or do you have a hard time trying to figure out who is the recipient of the value you are delivering? A culture of “us versus them” may keep workers away from collaboration

Does the organization Respond to Change over Following a Plan?

Or are we all so worried about scope creep, we have a rigorous change policy? Or has the pendulum swung the other way, and you’re experiencing the “Chicken Little -sky is falling” scenario all the time?

Acknowledging the Agile Manifesto and how an organization may adopt their culture to it, is one of the first steps to agility.

Twelve Principles
To be honest, I find the majority of teams I work with have no understanding of the 12 Principles of Agile. How can that be? Does leadership really believe a framework will work without other changes? Yes, it is hard. Yes, someone will always be unhappy. Welcome to the real world.  If you fail at adopting Agile, and you haven’t tried to change culturally, is it really Agile that doesn’t work? Are teams working to be Agile, while the rest or the organization continues with business as usual?

Think of the simple scale from “Somewhat Agree to Somewhat Disagree”, and for each of the Principles score your organization.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (or just value delivery)

This allows our customers to see steady and ongoing progress towards are end goal.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Changes of scope may have an impact, but we need to quit complaining about change.

3. Deliver working software (value) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Reduce risk, increase collaboration, break work down into small pieces, and get feedback after each delivery.

4. Business people and developers must work together daily throughout the project.

If the team doing the work has no access to the recipients of the value, are you playing the “telephone game” with requirements and feedback?

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile teams are self-organizing, self-managed, and empowered to do what it takes to deliver quality value at regular intervals. If you’ve truly hired good people who want to do a good job, why micromanage them? Empower your folks, and see what happens. With any luck teams will learn to pick up the stick, and run with it.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Skip multiple emails, and meet face-to-face even if it is over the internet!

7. Working software (quality value) is the primary measure of progress.

If you’re not creating software, deliver small pieces that act as building blocks towards completing your value delivery.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

A little extra time here and there is okay. However if working 50 – 60 hours is the norm, it’s hardly sustainable.

9. Continuous attention to technical excellence and good design enhances agility.

Going faster doesn’t cut it if quality drops. The focus should always be on delivering quality.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Do you remember the 80/20 rule? We have a phrase “no gold plating”, so focus on what really matters to the 80%.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Learning new practices, and engaging regularly to ensure the foundation is sound enables teams to take advantage of emerging technology and practices.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Without continuous improvement, being Agile slips further and further away from reality.

Summary

Cultural change is key within organizations in order to really support the Agile Manifesto and its Twelve Principles.  Where does your organizations culture fall when using the Manifesto’s scales, and the Twelve Principles? Work to move the pendulum a little at a time as needed. The origins of Agile lie not in black and white answers but in collaborating to do what is best in our drive to deliver value. Your customers will be happy, and you’ll retain employees and keep them and shareholders happy.

When an organization decides they want to “Go Agile”, they usually go through a multitude of changes before they get into a rhythm of the method(s) they have decided to use.  Once a team gets into a rhythm of ‘going’, or just doing, they will most likely be so engrossed that they forget to look up and see where they are.  However, it is important that they stop at some point to examine how things are going overall in their Agile journey and whether or not their method(s) are working for them.

The most popular framework that teams choose when first moving toward being Agile is Scrum.  In order for a team to really grasp the idea of sprints and incremental development, they will need to do a number of sprints before stopping to examine themselves; one sprint does not give the full feel for the changes and mindset shift that occurs.  Whether they stop after 4 sprints or after 10 sprints, the team will usually feel one of two ways:  “Scrum seems to be working for us; let’s keep it up, using continuous improvement to get better, and examine again in another few sprints” or “this doesn’t seem to be working; let’s forget Scrum and just do the work”.

When a team feels that Scrum is working for them, they have usually tweaked the framework a bit to allow for their team to feel they are abiding by the Agile Manifesto the best they can to ensure value.  As teams work together, they will tend to work toward continuous improvement and look for ways to work with the customer to ensure their satisfaction.  They will strive to continue to tweak their process to be successful in being Agile.  This type of team is most likely tightknit and feels good in the rhythm they have gotten into—so much so that they may not want to stop to examine, but realize they need to.

The other feeling that comes out is the aforementioned “this doesn’t seem to be working; let’s forget Scrum and just do the work”.  When a team has been doing Scrum for a while and they take stock of where they are, they sometimes conclude that Scrum is more work than they want to expend.  They can see the ceremonies as too much time wasted or that the timebox simply doesn’t fit their needs.  When this happens, they typically chose to abandon the framework and simply ‘work’.  They could just leave Scrum behind and choose a different method to become more Agile, but usually that is not the case because they have come to believe that the road to Agile is the problem; not its implementation of the method or framework.  When the team abandons Scrum, they don’t just abandon the sessions, like sprint planning or retrospectives, they tend to abandon the mindset that being Agile instills.  As they move away from Scrum, they also are likely to shy away from concentrating on the customer and the value they can provide to the customer, which is the core of the ‘Agile way’.  They see the ‘failure of Scrum’ as ‘failure of Agile’ because somewhere along the way, they have equated the two: Scrum = Agile and Agile = Scrum.

As the team ‘does what they want’ and does not follow any Agile methodology, they can easily fall into the trap of ignoring the customer’s wants and needs to the point of missing the mark.  When this happens, we have to examine why the team chose to move toward Agile in the first place:  to deliver what is really needed/wanted and not just what is listed.  If they don’t feel Scrum is working, the team will have a tendency to focus on what they want to do and stuff they find easy. In the end, the product is not what the customer is looking for; there tends to be wasted effort and time.  This wasted effort then results in many other issues with the project/product like not meeting dates, going over budget, risking the cancellation of the project/product, etc.

With all this said, it is not every team that reverts to ‘just working the list’; some simply find other avenues to be Agile other than that of Scrum.  These are the teams that understand that Scrum is maybe not for them, but understand that their attempt to be Agile is not the problem.  These teams usually find a way to move to other methods more suitable, such as Feature Driven Development, Extreme Programming, or even Kanban.

It’s important to remember that the point is to take time and examine what it is that is working, or not working, overall.  Most teams do this at the retrospective, but that should be focused on the team and the sprint.  There should be a time when teams do a more encompassing retrospective that looks at the process as a whole, which would look at things like release planning and working with other teams in the organization.  It is crucial that they take stock of what is working and what is not so they feel empowered to make changes to be as Agile as they can be!

I recently visited my mom and sisters.  It’s about a four hour drive to where they live, so I stayed with them the whole weekend.  One morning, as we were all gathered in the kitchen, still dressed in our jammies, drinking coffee and chatting, my mom pointed to the aloe plant in the kitchen window.

Mom – “Look…it hasn’t grown in the last six months.  I don’t know what happened to it, maybe I overwatered it.”

Me – “Have you used it to treat any burns or cuts?”

Sister1 – “Nobody’s had any cuts to treat.”

Mom – “And we don’t cook around here, so no burns either.”  (We all laugh at this, because none of us cook muchJ)

Sister2 – “That must be it then, mom.  You’re not using it and it’s stopped growing.”

Me – “What do you mean?”

Sister2 – “Well, mom put it in the window so it gets light and people can see it, but nobody’s using it.  It can’t compete with plants that provide food or that look pretty.  Its strength is in healing.  It’s not doing what it’s best at, so it just sits there, feeling left out, sad, and useless.”

Now, although my sisters and I have been called smart-alecks and wise-guys a time or two, we’re not generally known to spout profoundness or wisdom, especially that early in the morning.  But my sister’s comment struck a chord for me.

Not that I think plants have feelings or anything, it was just a reminder of how powerful it is to feel appreciated for what we can contribute.  Not what we should do, but what we can do….the former is someone else’s yardstick of “good”; the latter is ours.

Simple, genuine appreciation offered by others builds confidence, gives us a sense of meaning and purpose, and sustains us in stressful times.  That conversation also reminded me of a quote I read not long ago by Ram Dass:

“When you go out into the woods and you look at trees, you see all these different trees.
And some of them are bent,
And some of them are straight,
And some of them are evergreens,
And some of them are whatever.
And you look at the tree and you allow it.
You see why it is the way it is.
You sort of understand that it didn’t get enough light, and so it turned that way.
And you don’t get all emotional about it.
You just allow it. You appreciate the tree.
The minute you get near humans, you lose all that.
And you are constantly saying, “You’re too this, or I’m too this”.
That judging mind comes in.
And so I practice turning people into trees.
Which means appreciating them just the way they are.”

As coaches, our job isn’t to judge what a person has to offer as good or bad.  It isn’t to fix or change them.  Our job is to appreciate them just the way they are, to support them as they learn and grow, encourage them, mirror what is, and help them be the best “them” they can be.

I’d love to hear your thoughts….did these examples speak to you?  What did they say?

Each year, the notable Scrum Alliance hosts a Scrum Gathering in an energetic city somewhere in the US.  This year, 2015, the Scrum Gathering was held in Phoenix, AZ at the Talking Stick Resort.  During the 3-day conference at the beginning of May, there were many speakers who took the stage in an effort to share knowledge and experience with those of us who attended the conference.

The week started off with a keynote by Mike Cohn.  The basic theme of his keynote was “#ICouldBeWrong”.  During his “Let Go of Knowing: How Holding onto Views May be Holding You Back” presentation, he spoke of how we as Agilists have long thought certain things were either good practice, part of Scrum, or a belief we have held onto for some time.  He talked about how we may have some beliefs which we consider to be known to us as definitive things that are without question.  We also have other beliefs that are just that—beliefs, or things we have heard, seen or thought and hold onto.  We, as Agilists, need to be open-minded enough to realize there is a difference between these two types of beliefs and that some of the things we believe, even those of the ‘known type’, can be questioned and possibly even refuted.  Mike Cohn used an example where, for a long time, he believed that a team needed to be defined and fixed then, after working with a few teams that weren’t, he managed to change his belief to one that said that teams can be more dynamic and change periodically.  The main thing I took away from this session was that some of the things I think I’m doing that are ‘right’ could actually be the ‘wrong’ thing to do; I need to look at each situation with an open mind and made decisions or recommendations based on those situations.

After the opening keynote, I moved on to the session for which I was the speaker: “Everybody Out of the Pool – Agile Teams and Dedication”.  In this session, which was attended by a number of people, I talked about moving from the concept that project teams are built out of resource pools to the Agile mentality that everyone is a person and they all bring something different to the team.

The remaining portion of Monday was spent in various sessions of 45 or 90 mins each.  My most notable on Monday was a session on coaching conversations.  This was a workshop that was led by Martin Alaimo that centered on the Coaching Canvas.  This workshop gave me great insight into better ways to help clients understand themselves by asking the right questions to learn more about their: 1) goals, 2) impediments, 3) facilitators, 4) action plan.  By using the ‘coaching questions’, from the question bank on the site, you are able to better understand exactly what the needs and wants of your client are and how to help them achieve the goals.

Tuesday morning started out with a series of PechaKucha presentations.  There were 10 in all, with a wide range of topics.  I enjoyed this very much as it was just enough to keep my attention; there was not too much detail.  A couple of the notable topics for me were “Getting Your Team from Good to Great”, “People over Process”, and “So You Want to be a Scrum Trainer”.  Each of these presentations caused me to learn things I didn’t know before, or helped to strengthen my understanding of the topic.  One of the presentations that hit the trainer nerve was the “So You Want to be a Scrum Trainer”.  It really pointed out that we are not just ‘lecturers’ but those of us that do Scrum training must really understand our audience and what they need; but more importantly, we need to understand what they bring to the conversation.

Tuesday afternoon was much like Monday in that it consisted of various sessions of 45 or 90 mins each.  The most notable for me on Tuesday was a session led by Bob Galen where we discussed things that were said by coaches, either those in the room or others, that were anything but encouraging to teams.  After hearing how some coaches may say things like “You do it because I said so and I’m the coach” or “I’m the coach, so you know I’m right”, it got me to thinking about the things I say.  While I would never say these types of things, it provided insight for me to think twice about things I would say before saying them and also to help others from making the same kind of mistakes.

The last thing on Tuesday was a session of Ignite Talks.  Beginning on Monday morning, anyone with any particular topic they wish to present posted those topics and the attendees of the conference voted for the topics they wanted to learn more about.  The Ignite Talks on Tuesday consisted of 10 topics for 10 mins each of those selected by attendees.  There were a number of topics that ranged from Kanban to keeping teams engaged.  While there was no one topic that stood out for me, all of these topics were fun to listen to and contained great information.

On Wednesday morning, while most of the attendees were in Open Space, I attended a workshop on becoming a CST (Certified Scrum Trainer).  The workshop was facilitated by 3 members of the CST TAC (Trainer Approval Committee) that are responsible for interviewing candidates for the CST designation.  During the workshop, those of us in attendance were informed about how the process works, what was expected of us, and were given a chance to ask questions of the TAC members.  During this session, many questions were answered from various attendees.  At the end of the workshop, I walked away with a better understanding of the process and how it would apply to me.

During Wednesday afternoon, there was a closing keynote by Jim McCarthy where he discussed the value of freedom in our “software culture” and how we have obligations to push movements forward so that we can design our culture to meet the needs of the many.

Overall, the Scrum Gathering Phoenix 2015 was a great opportunity to catch up with some old contacts and meet some new ones.  I managed to learn a lot and gain insight into myself and my beliefs as an Agilist.

Looking forward to the next Scrum Gathering!!!

Do you often feel tensed thinking of tasks started and not completed?  Do you find interruptions frustrating and wish they go away so you can complete tasks started a while back?

If you do, you are not alone and you are likely to experience the Zeigarnik Effect, named after Bluma Zeigarnick, a Lithuanian-born psychologist. In the late 20s, she noticed that waiters seemed to remember complex orders in progress, but forgot all about them when completed. She conducted further studies in which people were required to complete puzzles while being randomly interrupted. It turns out study subjects remembered the interrupted tasks 90% better than the completed tasks and associated interruptions with feelings of frustration. And during the last 80 years, it has repeatedly been demonstrated that people experience unpleasant thoughts about an objective that was once pursued and left incomplete (Baumeister & Bushman, 2008, pg. 122).

Whether it’s something we want to finish or not, it’s our mind’s sometimes incomprehensible but overwhelming desire to finish what we’ve started. Our memory signals the conscious mind, which may be focused on new goals, that a previous activity was left incomplete. It seems to be human nature to finish what we start and, if it is not finished, we experience a state of tension which manifests itself in improved memory for the uncompleted task. As uncompleted tasks accumulate, our level of anxiety will increase and it becomes difficult to pursue any single objective with uninterrupted concentration.

Unfinished tasks tend to constantly interrupt our thoughts, a sort of auto-pilot system reminding us of what needs to be completed. The cognitive effort that comes with these intrusive thoughts of the unfinished task is terminated only once the person returns to complete the task.

Interrupting our efforts to finish a task before it’s complete also seems to interfere with our ability to accurately estimate our productivity, lengthening our estimate of how much time we’ve spent and how much longer it will take us to finish, according to a 1992 study by Greist-Bousquet & Schiffman.

This automatic system that signals our conscious mind that we have unfinished business, provides evidence of a neurological basis for the teachings of Peter Drucker, Jim Collins, Stephen Covey,  and others on the crucial importance of choosing what not to do. Peter Drucker emphasized the importance of using resources on the 10% of things that make 90% of the difference. He described leadership as doing the right things — versus management, doing things right. Likewise Jim Collins describes his “Stop Doing List” as the cornerstone of how he allocates his most valuable resource: time. Stephen Covey espoused effectiveness more than efficiency; getting the right things done at the expense of getting lots of things done.

Our capacity for work and our capacity for attention are limited and are governed by physical laws. Kanban Systems leverage the Zeigarnik effect and help individuals and organizations stay focused on what is important, reduce stress, and improve predictability, morale and productivity. I will show you how in my next blog.

Are you noticing the Zeigarnick effect around you? Please leave a comment below.

_____________

References

Zeigarnik, B.V. (1927). Über das Behalten von erledigten und unerledigten Handlungen (The Retention of Completed and Uncompleted Activities), Psychologische Forschung, 9, 1-85

Baumeister, R.F., & Bushman, B.J., (2008). Social Psychology and Human Nature. United States: Thompson Wadsworth.

Greist-Bousquet, S., Schiffman, N. (1992). The effect of Task interruption and closure on perceived duration. Bulletin of the Psychonomic Society, 30(1), 9-11

Teams that are using the Scrum framework to become more Agile usually use velocity as a metric to help them understand how much value can be accomplished in a given sprint—which also gives a good idea of what value the release can hold.  This metric is something each team strives to improve through continuous improvement of their processes and teamwork.  However, the meaning is not altogether taken at face value…

When you think of velocity, what do you think of?  Do you think about the higher the number, the better or equating velocity to the amount of work the team does?  Does your team strive for high velocity?  If so, why?

Teams use velocity for a multitude of reasons; few of which are actually valid.  These valid reasons usually include improving themselves, using it for planning purposes, and sometimes for proving their abilities as a team.

When you remove the valid reasons, there are many other reasons that velocity is used as a metric, and some of them are not so ‘friendly’ to the team, or to being Agile.  A few I have heard or seen include: measuring the team’s pace, using it to force the team to do more than they are really capable of, using it to mix up teams, having it prove that “Agile fails”, apply it as a way to show risk to the project, and, maybe the worst, using velocity as a way to push the team into a ‘death march’ to completion.  I have seen many teams that end up failing because someone, who may not understand the purpose of velocity, pushes the team over the edge and they “storm” over how they should be working.

When we look at velocity, it is indeed meant to measure the throughput of the team in a given sprint—how much the team completed during the sprint.  The original intent of this measurement is to assist in planning the amount of work that the team can accomplish in a sprint, and therefore how much scope can be accomplished in a given number of sprints, or a release.

By looking at the definition and the original intent, you can clearly see how the intent can be morphed or twisted into some other purposes, like those listed above as the ‘not-so-friendly’.  This is not unlike many large companies in their infancy of an Agile transformation—they are not sure what to do with this new metric and so they use it as they see fit, even if it’s not the purpose.  When this happens, it tends to cause riffs inside the teams and across teams.  The worst scenario is when organizations that do not have the proper training or coaching in Agile attempt to ‘read between the lines’ and begin to infer things about the team, such as how hard they are working or even whether they are working at all.

It is important to understand that numbers do not tell the whole story, but merely start the conversation.  The conversation is worthwhile so that the team, and the organization, can better recognize what is happening with the team and how they are attempting to become more Agile.

Another murky side to how some teams’ velocities are used is to compare team to team—as if a higher velocity by one team over another means there is a better team.  The idea that teams can be compared by simply comparing velocities is a bit absurd—there are so many reasons that one team’s velocity may be higher than another’s, which is more evidence that numbers do not tell the whole story.  When velocities are used to compare team against team, you find that it creates friction between teams.  As the relationship between teams is strained, the value that the teams produce begins to dwindle or be of less quality.

Velocity is one thing that a team should never compromise; their velocity is what helps to keep them on a more sustainable pace and helps prevent them from getting burned out.  The biggest thing that velocity gives a team is a way to keep from committing to more than they can realistically deliver.

After reading this, would you change how you measure your team’s, or teams’, velocity?  Does it change how you interact with other teams?  Feel free to comment on how you use, will change, or see velocity.

I get this question a lot. And I ask back “What business problems are you trying to solve?” Each method has great potential when applied within the right context. If you are already using one of them, it doesn’t mean that you can’t use practices from the other. You should adopt any practice that enhances your current toolset for solving business challenges.

Here is a good article that takes a pragmatic approach on how each one of the methods can be used based on what is best for your customers: What is Best, Scrum or Kanban? – http://www.agileconnection.com/article/what-best-scrum-or-kanban

CC Pace provides a variety of Agile services, and we can help you build your toolset as your business needs change. This blog site is a great forum to ask methodology related questions. What do you want to learn more about?

Have you ever wondered exactly what types of things a team does during a Sprint or what they should be doing? A team usually has one thing on their mind during a Sprint: “complete our commitment”! However, there is a bit more wrapped in that commitment getting completed which the team needs to consider.

Something teams use to know if they complete their commitment is a Definition of Done. As a team develops their Definition of Done, they assume certain things, which frequently center on the most obvious like coding and testing, will be completed during the Sprint and base the Definition of Done on those. Nevertheless, there is much more that should be considered for the Sprint. By using what I call “The Sprint Bubble” as a guide, a team can construct their Definition of Done to ensure they do everything they need to do in order to complete their commitment.

In addition, by using the Definition of Done as a guide, the team will be much more comfortable with what they expect to complete during the Sprint and will identify things which should not be done. It is worth reviewing those as the team builds the Definition of Done as well.

A lot of teams think the Sprint is nothing more than a ‘mini-waterfall’-type timebox; which is not the case at all! While there are many things which go on during the Sprint, they are absolutely not done in a ‘mini-waterfall’ style. Using “The Sprint Bubble” (shown below), you can more easily identify the things that have a place, or not, in the Sprint. I like using the MoSCoW-based categories—“Musts”, “Shoulds”, “Coulds”, and “Won’ts”—to explain. These things, regardless of category, are simply a way to construct the Definition of Done. There are times when you may have a bit of order to be followed, but these things just need to be completed.

First, let’s look at the “Musts” that belong in “The Sprint Bubble”. The most obvious things are develop and test code. However, given that testing is usually broken out into multiple different types—unit, integration, functional, story, system integration, performance, user acceptance, and so on—there will be some that may fall into other categories. With that in mind, the unit testing and functional testing would be a must because they help to ensure the stories are completed and functioning correctly. Also, many teams are moving more toward story testing (also referred to as acceptance testing), which is defined as testing around each and every story to ensure it meets the acceptance criteria of that story. When teams are doing this style of testing, it is also considered a must. Another must is integration testing; teams need to ensure their pieces work together and integrate well in order to make sure the entire product works well.

What about things like design or user interface components? These would be categorized as “Shoulds”. Before we talk about what things are categorized as shoulds, what does it mean to be a should—well, it means that it is something that belongs in the Sprint, but will not necessarily cause a ‘break’ in the application that’s being built or overall Scrum framework if it’s not. A lot of what you find categorized as shoulds are designated as other teams’, or organizations’, responsibilities in larger companies but would be musts in companies that don’t have these other teams or organizations. When you have a company without these other types of teams, design or user interface components should be done inside the Sprint and be part of the team’s Definition of Done. When a company has a different team or organization that does these types of things, they may decide these things are to be done and approved prior to the story being put into a Sprint. The one thing that many teams seem to forget is documentation. Documentation is a should, and therefore belongs in the Sprint, which helps to ensure it never gets overlooked. Another thing that would count as a should is that of system integration testing. System integration testing is very important to the overall product and is required to ensure the newly created product plays well with what the organization already has in place.

That brings us to “Coulds”. There is some easy stuff that could be put into a Sprint based on the company and the ability to do it in the timebox. Coulds are things that some may argue belong in the shoulds, but the way the organization is organized or the way the environments are set up may more appropriately put them in could. Probably the most popular detail that falls into coulds is user acceptance testing. This is something that seems to have the most problem being put into a Sprint due to the amount of time that the UA testers can lend to the Sprint timeframe or environment setup. If you have none of these kinds of restrictions, the user acceptance testing can most definitely go into the Sprint and therefore will allow for a release to production after the Sprint. Performance testing is another could, but will also be done in bits as other types of testing are performed (another topic for another day). I try to have performance testing be more a should than a could, but again relies on how the organization and its environments are set up.

Well, now we are at the “Won’ts”. A few things definitely do not belong inside a Sprint and need to be defined as such. One of these is defining acceptance criteria for the stories already in the Sprint. If you do not have acceptance criteria on a story, then the story is not eligible to be put into the Sprint in the first place. Another is defining a story to work in the current Sprint. If a story is not well understood, it cannot be accurately estimated, which also means it cannot be worked properly and cannot be put into the current Sprint.

Hopefully by better understanding what work is part of a Sprint, a team’s Definition of Done can be better constructed and followed. By using “The Sprint Bubble” as a guide, it helps the team solidify what should be part of their Definition of Done based on their environment and company policies. Having a solid Definition of Done means the team can ensure they are producing the highest quality of a valued product at the end of each Sprint.

In previous posts, I talked about what the “Get It Done” (GID) and “Just Do It” (JDI) patterns look like in organizations.  Today I’ll talk about another cultural pattern.

“MAKE IT SO”
If you’re a fan of “Star Trek: The Next Generation”, then you’re familiar with this phrase.  I can see it now….Captain Jean-Luc Picard standing on the bridge of the U.S.S. Enterprise, facing a situation requiring action.  He asks for options, listens to recommendations, and conveys a decision to move forward by telling the crew to Make-It-So.  His decision communicates “what” needs to happen, but he trusts the crew to figure out “how”.  This is the essence of a Make-It-So (MIS) culture, a pervasive attitude of leadership throughout an organization, resulting in an environment that supports growth, encourages exploration, demands excellence, and emphasizes accountability.

In an MIS culture, everyone has a place in the fabric of the organization….they are valued and valuable, and they know it.  Everyone has an important part to play….and they are expected to play it.  People are skilled and competent….and because they are, they’re confident.  People are empowered, they are “granted permission” to contribute ideas, to make decisions, to take risks…to “make it so”.

Ten characteristics I’ve experienced in an MIS culture include:

• Possibilities
  “When nothing is certain, everything is possible.” – Margaret Drabble
  We are informed by, but not tied to, what was.  We are grounded in the here and now, yet remain open to what could be.  We don’t drag ourselves down with visions of doom, but maintain a sense of hope and optimism.
• Focus
  “Concentrate all your thoughts upon the work at hand. The sun’s rays do not burn until brought to a focus.” – Alexander Graham Bell.
  When vision and purpose are visible and shared, it provides us context.  We know the direction and why, so we can act and make decisions accordingly.
• Interdependence
  “No man is an island, entire of itself; every man is a piece of the continent, a part of the main.” – John Donne
  We know it “takes a village” and we can’t do it alone.  Success depends on the combined strengths and contributions of everyone.
• Trust
  “The key is to get to know people and trust them to be who they are.  Instead, we trust people to be who we want them to be, and when they’re not, we cry.” – David Duchovny
  We trust in each other’s positive intent, and believe everyone does the right thing at the right time with the information they have. We act, make decisions, and move on.  While we reflect on what we learn from experience, we don’t undermine confidence by second guessing ourselves or others.
• Integrity
  “It’s not what we profess, but what we practice that gives us integrity.” – Sir Francis Bacon
  We seek to know ourselves, to be ourselves, to be proud of ourselves, our organization, our place in it, and our contributions.  Our actions are congruent with who we are, our beliefs, our passions, and our strengths. We own our decisions and choices, and their consequences.
• Discipline
  “Talent without discipline is like an octopus on roller skates. There’s plenty of movement, but you never know if it’s going to be forward, backwards, or sideways.” – H. Jackson Brown
  We strive for excellence, and excellence requires discipline in little things on a daily basis.
• Encouragement
  “There is no such thing as a “self-made” man.  We are made up of thousands of others.  Everyone who has ever done a kind deed for us, or spoken one word of encouragement to us, has entered into the make-up of our character and of our thoughts, as well as our success.” – George Burton Adams
  We grow through support and encouragement, which helps us spread our wings, improve, gain confidence, and reach our potential.
• Diversity
  “We need to give each other the space to grow, to be ourselves, to exercise our diversity. We need to give each other space so that we may both give and receive such beautiful things as ideas, openness, dignity, joy, healing, and inclusion.” – Max de Pree
  We know that too much sameness stagnates an organization, so we explore and leverage differences to open the door to possibilities.
• Courage
  “Courage does not always roar, sometimes it is the quiet voice at the end of the day saying “I will try again tomorrow.”” – Mary Ann Radmacher
  The rewards are greatest when we take chances, risk exposure, and step outside our comfort zone.  Leaders nurture and reward courage.
• Resilience
  “The secret of life, though, is to fall seven times and to get up eight times” – Paolo Coelho
  It’s not just a matter of having the will to get back up and keep on going.  We must also have the “health” to do that.  As an organization and as individuals, we take care of ourselves so we can continue to bounce back.

An organization which cultivates an environment like this, is one where people are important.  And when people are important, they collaborate, they innovate, they adapt quickly to change, they “dare greatly”…..and amazing things happen.

Gee, that sounds an awful lot like an Agile environment!

What do you think?

I spend a lot of my time coaching individuals, teams, and organizations interested in reaching higher levels of performance through the use of Agile methodologies like Scrum, Kanban and SAFe. Some clients expect me to tell them what to do step by step, while others are interested in learning how methods work so they can determine what practices to use as their circumstances evolve. The approach that leadership teams prefer usually reflects the problems they are trying to solve, as well as their domain of expertise, their size, their culture and their organizational purpose (for-profit, non-profit, government, etc).

In conversations with leadership teams, we discuss patterns and practices they could help institute or amplify in order to sustain their Agile transformation journey.  Our message, reinforced by all success stories in the industry in the last 15 years is clear: The success of an Agile transformation, regardless of the practices adopted, is directly proportional to how well people in leadership roles at all levels understand, exercise, and constantly improve their Agile mindset.

Leading with an Agile mindset means letting go of the traditional notion of leadership as strategy and control from the top according to a pre-determined plan of action. In times of rapid change when high levels of complexity and uncertainty are the order of the day, leaders can no longer assume they can know or control what goes on. Individuals at all levels must adapt constantly to changing conditions using their best capabilities and judgments in the moment.

In these circumstances, the role of leadership in Agile organizations is to shape the understanding, development, and learning of team members so they can act both independently and in concert with the goals of the whole organization. Leaders need to become coaches, coaching across the organization as well as individuals:

• Individual Coaching: You institute a style of leadership that is participative, servant, transparent, and unleashes the intrinsic motivation of a workforce that seeks mastery in their respective skills
• Organizational Coaching: You focus on understanding and managing the organization as a whole, optimizing the interdependence of teams and departments in order to minimize waste and maximize effectiveness

In practice, we observed that effective leaders in Agile organizations are also effective coaches. I constantly meet people who have a natural coaching mindset and they don’t even think of what they do as coaching. Here are three definitions and models of coaching that have emerged in recent years:

• Coaching is a process that enables learning and development to occur and thus performance to improve. To be a successful Coach requires knowledge and understanding of process as well as of the variety of styles, skills, and techniques that are appropriate to the context in which the coaching takes place.– Eric Parsloe, The Manager as Coach and Mentor
• Coaching is unlocking a person’s potential to maximize their own performance. It is helping them to learn rather than teaching them. – John Whitmore, Coaching for Performance
• Coaching is an interactive process through which managers and supervisors aim to solve performance problems or develop employee capabilities. The process relies on collaboration. – Richard Luecke, Coaching and Mentoring

Leaders in Agile organizations understand that coaching creates a learning environment where individual and collective challenges are the first priorities. Coaching skills enhance their management tool-set in a way that benefits themselves, their staff (those who are coached), and their organizations.

Trust – The Foundation of a Coaching Relationship

Trust has been defined by some as the ability to be vulnerable (Schooman, Mayer, and Davis, 2007). Implicit in this definition is the assumption that when you trust someone, you’re willing to be open, less guarded about your weaknesses and more candid about your opinions and ideas.

In his 1993 dissertation, A Construct of Trust,  Dr. Duane C. Tway, Jr. defines trust as “the state of readiness for unguarded interaction with someone or something.”

And in Rhetoric, Aristotle, 384-322 BC), suggests that Ethos, the Trust of a speaker by the listener, is based on the listener’s perception of three characteristics of the speaker: competence (correctness of opinions), character (reliability – a competence factor, and honesty – a measure of intentions), and the goodwill of the speaker (favorable intentions towards the listener).

When a manager uses a supervisory approach, the relationship between the manager and their subordinates is based on expertise. Boundaries are strictly maintained. Trust, while relevant, is not a key component. The relationship is embedded in the hierarchy of the organization.

When managers coach, the relationship between them and their subordinates is based on both expertise and on abundance of trust. Subordinates trust their managers to do the right thing for them, for themselves, and for the organization.

Samuel B. Bacharach, director of Cornell University’s Institute for Workplace Studies conducted extensive research and wrote over twenty books on management, organizational behavior, and industrial relations. His research indicates that organizations that do not embrace a coaching culture perpetuate a static culture of inertia, bureaucracy, and control. In contrast, coaching is a characteristic of organizational cultures that value innovation, creative thinking, problem solving, growth, and change.

Bacharach points out that “a coaching relationship requires that the protégé (the person being coached) views the coach as someone who possesses the expertise of a good supervisor, but who is simultaneously as trustworthy as a good friend. This combination of expertise and trustworthiness composes the personal integrity of the coach. The more your protégés believe in your personal integrity, the more committed they will be to you, and the greater the likelihood of your success as a coach.”

In another study, C. Ken Weidner, an assistant professor at the Center for Organization Development at Loyola University Chicago, found that trust in the supervisor is associated with better individual performance.

You don’t need to be a trained professional coach in order to include coaching in your set of Agile leadership skills. You have to be able to tell your employees “I know how to do it,” or, “I’ve been there and done that,” without giving them the impression that you think you know it all. To establish or amplify trust, Bacharach recommends you let your protégés know that:

• Confidentiality is the golden rule
• You have their interests in mind when making decisions in the workplace
• They have the ability to speak freely to you
• You are open to learning new things and some of those things can be learned from them

Trust is the foundation for coaching relationships. It is also the foundation for what you want your organization to become.

The Supervisory and Coaching Mindsets

Both coaching and supervisory relationships exist within the hierarchical dynamics of an organization, yet they are fundamentally different.  A coaching relationship temporarily suspends the hierarchical structure, and is a partnership based on the candid, free-flowing transition of ideas and information between coaches and their protégés, which serves to support, reinforce, and motivate both.

Coaching holds that employees potentially possess the best answers to the problems they are faced with, and that the coaching process helps them discover the sources of those answers within themselves.

Leading involves both supervising and coaching. As a proactive manager or leader, you perform each of these two different roles, and each is characterized by its own mindset. Moving between these roles requires a subtle mind shift. Here are several examples:

Let’s look at several examples of how a supervisory mindset or a coaching mindset can influence the way we communicate with others:

• “I suggest you complete your work in the order that you receive it.” – The supervisor focuses on coordinating work rather than facilitating it.
• “Since our last scheduled meeting, you’ve been doing a good job. Keep up the good work.” – This statement is an evaluation of job performance and is characteristic of a supervisory mindset. There is no suggestion of a plan to develop skills together or of a partnership, both hallmarks of the coach-employee relationship.
• “I understand the tight deadlines, the constant pressure from customers to provide the best service, and the intense competition that are all a part of your job. How do you think we can continue to improve the organization and ourselves given these conditions?” – This is a coaching statement. The speaker is empathetic and shows expertise regarding the current situation. The speaker indicates an interest in partnering with the direct report.
• “Working closely with you is very helpful, because not only do you improve on your abilities, but working with you also enables me to isolate those areas that seem problematic in general for employees in your position.”  – The sense of partnership communicated here indicates a coaching relationship.
• “I appreciate your coming to me for assistance. It takes a lot for people to recognize their limitations and to know when they need to seek advice from others. In my experience, there are a few different ways we can approach solving this problem, so let’s work together to think of a feasible, realistic, and desirable solution.” – The sense of partnership communicated here indicates a coaching relationship.

Next Steps

Mindsets like Agile Leadership and Coaching are critical to the success of an Agile transition in your organization.  It takes practice to be good at them, and that means you have to go out there and do it. If, in the process of coaching, questions or challenges come to mind, we’d be delighted to hear from you.

If you read this far, you probably enjoyed this article and I hope it stimulated ideas you can start using at work.   I greatly appreciate your curiosity, and hope you stay in touch! Let me know if we should expand on this topic or if there are other topics that you would like to read about.

Scrum purists will tell you co-located teams are the way to go. If only it was that easy!

As large organizations adopt scrum, they find themselves struggling with how to be more Agile when many of their teams are distributed. As coaches and trainers, it is our responsibility to support this reality.

There are many blogs and articles like this one on the web that talk about working with remote teams.

Many of the articles I see offer common sense tips like:

• Make the most of tools for instant messaging, video conferencing, and shared content.
• For ceremonies, use video conferencing whenever possible.
• Ensure Team Agreements, Definition of Done, and Definition of Ready are in a shared location.
• Team Agreements need to include core hours when everyone will be on instant messaging.

Here are some of my own more unique suggestions:

• Dealing with time zone differences – Although ceremonies should be at the same time/place whenever possible, consider alternating times by month, or sprint. For example, on odd months favor east coast times, while in even months favor west coast times.  Don’t do too small of an increment (like daily).
• Time for a celebration – Ensure everyone on the team, regardless of location, goes out and celebrates. Schedule an extra 15 minutes post scrum to discuss what everyone did. Get creative….hold virtual “coffee breaks” or “pot lucks”; celebrate personal events (such as birthdays, births, leaving, etc) as well as team accomplishments.
• Tracking Sprint Progress – Utilize your tools’ dashboard during daily scrums to show the teams burn-down. Don’t micro-manage tasks. Insist team members keep tasks up-to-date reducing ETC to keep burn-downs current.
• Product Owner – As a Product Owner (PO), engage fully with the team to ensure collaboration leads to comprehensive understanding of each story. Ask questions. Update stories in real-time during team grooming to clarify understanding. It is easy to leave PO acceptance of stories until it is too late for developers to make changes. Instead keep an eye on story progression, review stories as soon as they are ‘done’.
• ScrumMaster as team facilitator – As a Scrum Master (SM), your role is especially important with distributed teams. Pay attention to how members interact. Is everyone participating in ceremonies like grooming and planning? Ask questions to draw out quiet members. Also, just because you are the facilitator, doesn’t mean you have to “be in charge”. Don’t forget to turn items like tasking stories over to developers. Just sit back and listen while they do the work.  Consider a SM for each location (e.g., if you have part of the team together on the east coast and another part together on the west coast, use a SM in both places).

There’s no doubt about it…..it’s harder for remote teams to achieve the same collaborative environment that co-located teams can. But it’s not impossible….with a little elbow grease and TLC, your distributed team will shine!”

In a previous blog, “The Reality of T.E.A.M”, I talked about Agile teams being dedicated, or part of a ‘permanent’ team that focuses on a single solution and remains together over time.  Another big factor of an Agile team is that they are cross-functional in nature.

What is a Cross Functional Team?    
When the topic of cross-functional teams comes up, there seems to be varying opinions that come out.  What does it mean when I refer to teams being cross-functional?  Does everyone on the team have to be able to do every job?  Do all team members have to know every detail of everything that goes on inside the team?  Does the team have to ensure that they can complete their solution?  Let’s look at what cross-functional means for Agile teams that I work with.

If you want to define it, you will most likely find that it means something like “a group of people with different functional specialties or multidisciplinary skills, responsible for carrying out all phases of a program or project from start to finish.”[1]  If you stick with this definition, you may find that you do not have to have a team where everyone on the team knows how to do every job on a team, but more that it is meant to keep members focused more on their role in moving the product forward than on their title.

Now that you’re on a Cross Functional Team
When the members of a team hear they are to be cross-functional, I’ve seen them get a little uneasy thinking they have to become something they may not want to be or learn to do things they don’t want to do.  I call this their ‘mini identity crisis’ because these team members are so centered around their title defining what they are supposed to do, they lose sight of what it means to be a team.

Team members will hopefully come to understand that becoming part of a cross-functional team means they will be focusing more on their role as a team member than on what their title is on their HR file.  Being a cross-functional team member is about ensuring you chip in whenever necessary and do as much as you can to ensure the solution is complete, and as good and valuable as it can be.

It’s not necessarily important that all team members know how to do everything, but it is important they work together, embracing common Agile principles from the Agile Manifesto and Principles, as well as principles that are found in Agile methods, such as “’Collective Code Ownership’ in Extreme Programming, which ensures the entire team owns the code and ‘Self-Organization’ in Scrum, where the team organizes themselves to get the job done.

Where does an Agile Coach fit in?
When coaching cross functional teams, I try to support and help them understand they won’t be losing their identity, but they are going to become part of a larger solution.  I emphasize that they’re not ‘against each other’, or ‘apart from each other’, but ‘for each other’.  I’ve found it’s important for team members to communicate and collaborate so they feel like part of a team instead of a pool of resources thrown together and asked to feel and behave like a team.

For all you sports fans—A Sports Analogy
Cross-functional teams remind me of football teams.  In football, there are multiple positions, both on the offense and on the defense.  While each member of a football team is most likely drafted onto the team to play a specific position, such as protecting the quarterback, the skills they possess for that position may also translate to other positions on the team.  For example, the player that protects the quarterback can use those same skills to get around the protection of the other team’s quarterback and sack him.  Just like a football team has players who are able to move to different positions in order to win the game, Agile teams use the same idea to produce the best possible solution!

Have you ever wanted to learn a new sport? Cricket, Golf or Rugby?

Where would you start? You may say, well I would find a coach. Maybe, you would consider reading a book, or watching a video, i.e. training!

So You want to learn a New Skill
Let’s use golf as an example.

If you’ve never seen a set of golf clubs, reviewed the rules of play, or know what a golf course really looks like, how will you learn to play? If you haven’t had any training, and you hire a coach, they will give you training. Coaches can’t help you improve your game until you understand the basics. If you’ve had training, a coach can help you incorporate what you’ve learned and give you pointers to help your game.

Training Lays the Foundation
Let’s introduce you to the course. It is played over 9 or 18 holes (sprints). The goal is to have the lowest number of swings possible (inverse velocity) while trying to get the golf ball from the tee into the hole. Holes differ from par 3’s to par 5’s. To move the ball from the tee to the hole, clubs are used. Clubs are grouped together by their primary use. There are drivers, irons, wedges, and putters. Once you’ve been trained on the basics of maneuvering through the course and using clubs, you can get out on the course. You practice, and practice, but your score is not what you want. You need “continuous improvement” to improve your score. This is where coaching comes in.

As Agile trainers, we like to get to know your organization. What are your goals and objectives of training? Are we introducing something new to your teams? Through learning about your organization, we can tailor our training specifically to your teams. Trainers can better provide a pragmatic approach by learning the big picture (how big and what type of golf course are we working with). Spend a little time up front with trainers to determine exactly what your needs are. Then rather than having them provide “out-of-the-box” or “by-the-book” training, you will get a customized approach that enables your teams to get the most out of training. Your teams will be introduced to Agile (the big golf course), its various roles (clubs) and ceremonies (swings). Together the organization will engage on a journey to establish best practices to enable organizational success through Agile methods.

Coaching Helps You Improve
Coaches look at what you are doing. Do you have the right clubs? Are you selecting the right course for your play? Are you holding the clubs correctly? Coaches can help make sure you do not fall into bad habits. They can also help you to avoid or get out of sand traps. Coaches point out if you’re lifting your head during a swing, if your feet are positioned too close together, or if you are using the wrong club. They give you suggestions to try, and let you practice a bit more. If you don’t take any of their “suggestions”, improvement may only come from you working harder and harder to get to the hole. If you take their suggestions, your score will undoubtedly improve. In fact, the objective is to show continuous improvement. A golf coach may not only watch your swings at a range, but may play a few rounds with you. This helps them see the big picture of your play rather than just how you approach a par 3, specific lie or a long put. If gaps in your knowledge appear during full play, a coach may have to act as a trainer or suggest training.

As Agile coaches begin an engagement, they often want to assess where everyone is at in their use of their chosen Agile method. How much training has the team/organization participated in? How is practice going? Coaches do this by observing, asking questions, and participating with teams throughout a given time period. Within Scrum, a coach will follow you through sprints. Within the sprints, Scrum has many ceremonies to navigate where a coach’s impact can be seen. Observing how the team works together, and how well the team executes each ceremony allows a coach to provide feedback for improvement. An Agile coach may encourage the team to step out of their comfort zone trying something new. They may suggest teams engage roles a bit differently both inside the team and across other parts of the organization. A coach can help you review your results, and pick something to improve each iteration. Coaches work with specific individuals on improvements they can make, as well as working with the team as a whole. Some basics outputs of coaching will likely include:

• Establishing a cadence
• Standardizing Agendas for Scrum Ceremonies
• Clarifying roles, and helping team members perform within those roles
• Identifying and improving your velocity
• Establishing an environment for continuous improvement

Use Both to be Your Best
Just as in golf, where training and coaching gives you the foundations for play and then helps you reduce your overall score, Agile training and coaching gives you the foundations for Agile and then helps you increase your velocity. So invite your trainers and coaches on your journey to improving your Agile game. Your organization will thank you with more frequent delivery of working software.