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
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.
In December, I wrote a blog about the role of Scrum Master as a Facilitator, see it here. In today’s post I want to go into a bit more detail about the skill needed to be a good Facilitator. Many of you may be thinking that facilitating is easy, you just stand in front of the room and lead meetings. In fact, facilitators aren’t always in front of the audience, and it takes a lot of practice and skills to be a really good facilitator.
So what skills do you need to be a good facilitator?
- Be Present – understand how your body language, voice intonation and tempo impact the team.
- Do you have something distracting you? Check it at the door.
- Do you have hot buttons that the team pushes? Address them in your own time, don’t let them be activated in the session.
- Have a tool bag of techniques for driving to outcomes.
- How do you get teams to coalesce on a decision?
- How do you identify root causes?
- How do you ensure everyone feels heard?
- Address team dysfunctions – understand what is going on for the attendees.
Humans show how they are feeling about the process in many ways, so facilitators need a large tool bag to deal with personalities in the team like:
- The Whisperer
- The Loudmouth
- The Know-it-all
- The Silent One
- The Head Shaker
- The Doubter
- Have a good “Wrap Up”
- Ensure action items are assigned
- Ensure decisions are recorded
- Track and follow-up on parking lot items
All of these skills can be learned and practiced to make Scrum Master better facilitators. Use of facilitator skills extends beyond Scrum Events to everything the Scrum Master does.
To develop your skills and learn how to be a good facilitator, check out our ICAgile Team Facilitator certified class being held May 9-10 in Fairfax, VA.
In this class you learn and practice facilitating through a number of interactive exercises that relate to facilitating anywhere as well as to specific Scrum Events.
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:
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:
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:
- User Stories
- Technical Stories
Let’s take a look at each type of item.
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 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 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.
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.
If I told my 6-year-old daughter, Gracie, to get out a piece of paper and a pencil, she would likely get out a pencil and a piece of paper. But if I made the same request of my officemate, Ron, he would likely look at me funny and ask me why. Of course, if I made the same request of my 14-year-old daughter, she would completely ignore me but that’s another story.
So why the difference in reactions from Ron and Gracie? It really boils down to how we learn. As children, we learn by being fed information. During our early academic career, we take what teachers tell us as gospel. However, as we get older, we begin to question authority, as if it’s a sort of rite of passage to adulthood. I can hear those of you with teenagers, passionately shaking your heads. What I am trying to say is that adult learners need to be involved in the learning process. As adults, we need to understand why we are in this learning experience and how it’s going to make our lives better.
Um, CC Pace is an Agile coaching and training company, why are you talking about learning stuff?
Well, I am glad that you’re paying attention. Aside from the fact that CC Pace recently hired me to focus entirely on creating effective learning programs and I gotta do something to show them that I actually know stuff, how we learn stuff is part of how we create lean, mean, efficient machines…er, organizations. Just because you consider yourself an Agile environment doesn’t mean that you actually are! Waving the magic wand does not make a company Agile, although it’s kinda fun to suggest it to the senior leadership team to see if they bite. Agile needs to be embraced at the top AND at the bottom. Getting buy-in from the folks in the trenches means that the training needs to be created with them, very clearly, in mind.
Think of the last time you had to go to training because management said so, or because of a requirement for some regulation. What did you learn? Did you pick up lots of good stuff? Would you wish it on your worst enemy? Learning experiences that fulfill a check box are often set up for failure because we forget to explain how this information will ultimately help the learner. If we just chalk it up to a requirement or some mandate, then we have missed an opportunity to help reinforce the content.
It’s critical that a successful learning program understand that key difference; that adult learners need to be engaged with the process, rather than as just a passive participant.
So how do we get the learners engaged? Well, hopefully, you can see where I am going with this. If we start by successfully demonstrating how this information will connect back to the participant, then we stand a much better chance of helping the learner retain the information. Otherwise, participants are left pondering all of the other ways that they could be wasting time while still on the clock. But if the participant sees why the training will impact them, then they will submit to the learning process.
And as Johnnie Cochran once so famously said, “If the training reason is legit, then you must submit!” Ok, so Johnny never said that, but I bet he would have if he read this post. Ok, that might be a bit of a stretch, too. But it’s a nice way to remind ourselves of the importance of setting up a training for success. Keep this in mind when you are planning Agile training for a team within your organization. Thanks for sticking with me this long, how about we pick this up next time with some more ideas on building engagement in your learning program?
Last month I wrote about how transforming your organization from waterfall to Agile is like being on a diet (here). For me the next question is what kind of diet do you want to be on; or where do we start with our transformation?
As someone who has worked with countless teams to help them implement Scrum, I am always encouraging organizations to look beyond the team. Organizations need to do more than just teach their teams how to follow good Agile practices. They must walk the talk, and start following Lean-Agile practices themselves. The Scaled Agile Framework (SAFe) supports whole organization transformation.
What I like about SAFe, is it addresses the concerns I hear most often. Concerns such as: What do we do about our PMO? How do we handle CapEx/OpEx? How do we “control” a project reporting on its progress and tracking?
While SAFe may scare some small organizations with its “Big Picture” on the landing page. SAFe really isn’t scary at all. The SAFe framework gives you everything you need to consider to transform your organization from waterfall and a project-driven focus to using Lean-Agile methods to deliver solutions.
As with any change, start with leadership. Lay the foundation for success, and bring the entire organization along for the journey. For very large organizations, just expand the big picture from its three-layer default (Team, Program, Portfolio), and you will see the newer Value Stream layer. The Value Stream Layer will be a necessity if you have very large solutions with many hundreds or thousands of team members working to deliver a solution, but has many roles and concepts that will support even smaller organizations. Most notably for everyone is the article on keeping an economic focus.
SAFe is a diet for transforming your organization that given the basics of eating healthy, also provides a pick and choose menu so that each organization will have what it needs to be successful. If you haven’t taken a look at SAFe 4 with the added layer for managing Value Streams, I encourage you to do so. As for us old-timers it’s hard to find fault with a framework that supports all that Scrum has to offer at a team level, while addressing the rest of the organization giving us tools to ensure a successful Agile transformation.
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:
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.
- 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.”
- 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
- 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
- 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 1st 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 1st 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.
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.
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”.
- Provide a structured opportunity for team members to tell others about themselves, learn how others see them, and generate insights about themselves and others.
- Increase self-awareness of individual behavior
- Increase awareness about others’ behavior
- Expand Open area of each individual and the team as a whole
- 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
- 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.
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:
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.
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.
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.
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.
- 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
Meeting with a client a very interesting question came up: How many teams should a Scrum Master Scrum? They had been hearing that a the Scrum Master 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 and 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 Scrum Master does not translate well into the number of teams they can handle. Although it is a factor, in all honesty, there a number of factors which influence the decision, such the organizational maturity, team maturity, and project type, the value of the project and 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 PI’s, 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, they have worked through the forming, norming, storming, and are now in 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 have yet to establish Scrum Practices, then the Scrum Master should just be dedicated to one team because they will have many impediments to resolve, help team members understand and see value in Agile practices. Helping a newly formed team adopt the 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; 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.
Velocity, the measure of total story points completed in a sprint, is often misunderstood, and used as a “stick” against teams rather than a “carrot”.
I was once asked about trying to prevent a dip in velocity during team member vacations. Today I saw a post in LinkedIn titled “Tips and Techniques for Maintaining Velocity during vacation times”. The very question of how to keep velocity the same during vacations represents a gap in understanding of both why we use velocity and what velocity is measuring. Velocity is expected to dip when team capacity drops. Otherwise, we are falsely trying to use velocity as a prediction of what can be accomplished in a sprint. Where “management” stresses the need to have a steady velocity regardless of what is going on in a given sprint, it is like using a “stick” to motivate the team. It also encourages “gaming the system”, creating a false sense of security and velocity. We use delivery of quality software as our main measure of success. We use velocity to predict how much work we can commit to in order to become reliable, predictable, and consistent.
Most teams use points to estimate stories, the number of points completed is the teams velocity. The goal is to become predictable and consistent. Velocity is not normalized across teams, and cannot be compared across teams. Once you realize this fact, then it is easier to accept an explainable dip in velocity. Note: If you are following SAFe (Scaled Agile Framework) and trying to normalize points see http://www.scaledagileframework.com/iteration-planning/ In Safe, a 1-point story is normalize, but story points vary from there. A SAFe teams’ velocity should not be compared to any other.
Given a team has been together for at least five sprints, and story points are being used for relative sizing of stories in a consistent fashion, the team’s velocity will begin to stabilize. Good Retrospectives will provide insight into improvements activities that may help increase the team’s velocity a point or two each sprint.
With a stable velocity and team, we can predict what velocity can be achieved for any sprint. If Monday is a holiday, or if one team member is on vacation for the entire sprint, ScrumMasters can help guide the team to not over-commit. Thus supporting a sustainable pace, and exhibiting the true value of velocity as a measure.
Let’s take a look:
Team Wolf has 6 members, and a velocity of 40 for a two week sprint. I calculate capacity (the number of hours available to work in a sprint) at 6 hours per person, per day. For Team Wolf, a 10 day sprint has 360 capacity hours.
One bank holiday during a sprint
Capacity is 324 hours, (6 * 6 * 9) resulting in a 10% lower number of hours in which to complete the sprint’s work. I would encourage the team to commit to approximately 10% less work and aim for a velocity of 36 points.
One member on vacation for the entire sprint
Capacity is 300 hours (5 * 6 * 10) resulting in a 17% lower number of hours for a sprint. I would encourage the team to commit to approximately 17% less velocity, or 33 points.
Velocity dips can happen anytime for a number of reasons. A planned dip is not something to beat a team up over. Achieving the teams’ committed velocity is an excellent carrot. Reward teams, and celebrate successes.
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?
In a previous blog I shared how unfinished tasks tend to constantly interrupt our thoughts, create anxiety and affect our productivity. Research has proven that in human endeavors, once expectations have been set, our brains seek a conclusion. If that conclusion is not forthcoming, the brain “stays open” to receive it. Zeigarnik effects result from our mind’s tendency to seek conclusion: when leaving tasks unfinished to focus on something else, we experience anxiety and intrusive thoughts about the uncompleted tasks. Since multi-tasking is simply diverting our attention from one task to another (basically making the new task an interruption), our brain won’t allow us to fully focus on the new task because we have left the previous one uncompleted.
Kanban core practices not only help alleviate these effects, they can spin the Zeigarnik effect on its head and use it to our advantage. Here are several ways how this works:
- One of the Kanban practices is to “Limit Work In Progress (WIP)” based on available capacity to complete the work. This practice supports our brain’s natural inclination to seek closure by finishing what we started.
- Another core practice is to “Manage Flow”, meaning that we want to reach the optimum cycle times possible for everything we do. Besides a definition of “Done” teams define a definition of “Ready” that helps prevent starting on work they could not complete due to missing information or unavailability of subject matter experts (SMEs) along a value stream.
- In the event that information or people are not available, the affected work item is blocked visually indicating that work cannot continue until the blocker is removed. The physical act of blocking a work item cancels Zeigarnik effect by providing the closure our brains seek.
- Author and psychologist Perry W Buffington described the Zeigarnik effect by stating that people tend to remember negative experiences and feelings longer than positive ones. In our world this means that we hear more often from our stakeholders about what we haven’t done for them and less about what we delivered. Drawing upon this phenomenon, in our Kanban consulting practice we coach delivery teams how to consistently review with customers how delivered work is always completed at the expense of other work not being done. This leads to better prioritization, less escalations and minimizes interruptions. This approach is part of two other Kanban practices: “Develop Feedback Loops” and “Improve Collaboratively, Evolve Experimentally”.
Do you have a lot of unfinished business like a multitude of projects, tasks, and priorities that constantly change, requiring you to stop working on something and start working on something new or on something that was already on hold? Is the unfinished business (The Zeigarnik Effect) hunting you? Do you know how to forecast the capacity you or your team has and how to improve it?
High performance or high productivity require staying focused and avoiding multi-tasking or disruptions. Kanban practices can help you and they are easy to adopt alongside any other processes you already have in place. Our Certified Kanban Foundations Course will help you get started. Let us know what questions you have.
Zeigarnik, B.V. (1927). Über das Behalten von erledigten und unerledigten Handlungen (The Retention of Completed and Uncompleted Activities), Psychologische Forschung, 9, 1-85
Perry W. Buffington, Cheap Psychological Tricks (Atlanta, Georgia: Peachtree Publishers Ltd., 1996), pages 93-95.
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.
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.
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.
- 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.
- 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.
- 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.
- 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?
- 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.
- 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!
- 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.
- 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.
- 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.
- 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%.
- 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.
- 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.
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.
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
On a recent flight, I was reading about paying attention to detail in creating a dream room for your home. Attention to detail is important whether you are decorating your house, or building software. I work with Product Owners trying to write user stories so often, I instantly thought “I need to write about user story details”.
When teams are getting started with user stories, the inevitable question is where do my detailed requirements go? I think this is especially true when I work with huge organizations in highly regulated industries.
Details are Important
I’ve seen Product Owners (especially those that were formerly BA’s) fill entire user story description areas with details. In Agile practices, that flies in the face of what the user story is meant to convey. User stories are a trigger for a conversation. User stories should convey to the developer what the user wants to do and why. Once we get past the basics of the user story, then and only then, can we add details in the form of Acceptance Criteria and other attachments (wireframes, mock-ups, database excerpts, etc).
Before I go into user stories, I want to say that not all product backlog items (PBI’s) are user stories. PBI’s may be defects, technical stories, or spikes. If you are a feature team working on a web development project, then demand good user stories. However, if you aren’t in development, or the PBI isn’t a user story, then I question whether or not there is value in trying to force folks into the user story format (As a who, I want what, So that why). I do not question, ever, that we must provide detail along with conversation in order for the work to be performed, tested and accepted.
In organizations that have component teams working on ETL (Extract Translate Load) functionality, middle tier software services being written separately from the consuming team, or scrum teams not related to software at all (marketing, sales, audit), Agile still works and stories still make good PBI’s. Just don’t force yourself into the “user story” format if it doesn’t add value.
Check out Mike Cohn’s blog here for more on “back-end” stories http://www.mountaingoatsoftware.com/blog/writing-user-stories-for-back-end-systems
Sometimes we use the Agile Manifesto as a reason for skimping on what is needed. I fully believe in “Working Software over Comprehensive Documentation”. I am the first to ask, “who is going to read all this”. However, I also ensure that my teams get everything they need in order to provide quality results. If this means the Product Owner must work harder at getting the stories ready, then that is what they do. It is their job. Organizations need to know what a big job the Product Owner has. Just because we move from a waterfall version of requirements to Agile versions of requirements doesn’t mean the job takes half the time. In fact, it may take longer. Product Owners must break down stories, get details and be present for discussions with the rest of the team during story grooming/refinement sessions, or during development. If a developer wants more details the Product Owner must get them.
Creating User Stories
What does the process look like? To go from the initial creation of the title to a fully ready story can take any number of days. How much time and effort is spent on documenting the story depends on where it is in the stack ranked order of the backlog. I would rather not put all my effort into stories that aren’t coming up in the next 2 – 3 sprints. Even though I have hundreds of titles ready to go for months’ worth of stories.
Let’s take a look at some examples
The following user story could be broken down smaller, for a start though it meets the basic user story criteria telling who, what and why, but not how. It includes acceptance criteria, and if we were in a tool, I would expect to see supporting attachments.
Title: View Order Details
As an online customer
I want to see a summary of my complete order before I hit enter or submit
So that I feel confident everything is correct
- Ability to preview the order is available
- Preview includes shipping address, billing address, item list, shipping costs, tax, total , payment info (see wireframe attached)
- Payment info shows only the last four digits of card used
User stories are a trigger for a conversation. As we have the conversation a lot of questions should be asked… and results of those questions can be noted below the acceptance criteria.
Now let’s look at a technical story for a component team not invited to share in the front-end team’s user stories:
Title: ETL Sales Report – Team GoGo
Data must be loaded into the sales data warehouse in order to provide metric reports
- Data from XYZ database, tables 1, 2, 3 loaded into warehouse ABC table XXX
(see attached schemas)
- Stored procedures scheduled to run nightly to load data
- Data transformations run without error
- On error message “….” Sent to “….”
Here is a non-IT story:
Title: 2015 Security Audit – User Access Process System X
Audit Onboarding process with HR to ensure User Access requests follow approved processes
- Audit covers 80% of all request in last 12 months
- Manager’s interviewed and results documented (name, position, date)
- Document audit results following Procedure 123
- Auditor should not be able to request User Access without following the process
So where are the details?
In the Acceptance Criteria and associated documents! If something is missing, get it there before accepting the story into a sprint. If the story looks too big, break it into smaller pieces. Ensure you cover happy path and not so happy path options. Plaster your cube with domain models, object models, etc.
In January, I moved from Texas to North Carolina. When I was in Texas, I flew to client sites around the country. But the last few months I’ve been spending more time at clients on the east coast, and have been driving more often.
Now, my brain considers flying an opportunity to catch up on sleep. Driving on the other hand, is an opportunity to tiptoe-through-the-tulips, or anyplace else it seems. No map, no rhyme, no particular reason, even…..just random thoughts, reflections, conversions, explorations, and discoveries.
And if the day is sunny and bright, the traffic light, the scenery beautiful, and the music inspiring, I’m filled with the same freshness, optimism and excitement I felt as a kid on a road-trip. Yet at the same time, quieter, easier, more comfortable being with myself. I thought I’d periodically share a few of my observations from these road-trips. Not because they’re brilliant, or deeply philosophical, or earth shattering or anything, but because sometimes random thoughts are all I have.
Last week as I was driving back from NOVA (Northern Virginia), this song by Lee Brice came on the radio. I was singing along (not well, mind you), and it occurred to me (randomly, of course)….if the conversation took an Agile view, what would it say? So, I took a shot:
Today, outta the blue
Driving along, singing with the tunes
I heard him say, “What would you do,
If you’d never met me.”
I laughed, and said, “I don’t know,
I could make a couple of guesses, though.”
I breathed deep, my thoughts ran free
I said, “Well, Agile, let me see,
I’d do a lot more estimatin’,
I’d probably spend more time project plannin’,
Play the same ol’ schedule game
If I’d have never known your name
I’d still be doing that ol’ waterfall,
I probably never would have heard the call
Of a different way.
Now, I’m just a simple man
Unaware, yet pretty astute
And, I’d be looking for an option like you.”
I could tell that got his attention,
And I said, “Hey, did I also mention,
I wouldn’t trade one single day
For a hundred years the other way.”
Agile smiled and raised his brow,
‘Cause of course, he’s heard it all
I said, “Come on Agile, don’t you see,
If I hadn’t been so lucky, I’d be
Managin’ meetings for team members,
Reportin’ status to senior leaders,
Stockin’ up on ibuprofen,
Plannin’ stage gates every so often.
There’d be a project schedule in the hall,
And not one index card on the wall,
I’d keep candy in my desk drawer,
But I’d be in an office on a different floor.
And honestly, I don’t know what I’d do,
If I’d never met an answer like you.”
Well, that’s my version….how would your version go?
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?
When our yacht club saw membership dropping and was looking for a change, I called our Chairmen of the Board and suggested… a Kanban board.
Lucky for me, our Chairmen works in software for a well know online travel site. He knew just what I was talking about. After a short discussion, we decided to introduce the ideas of Scrum to the board. At our next Board of Directors (BoD) meeting I turned up, white board and 3 x 5 cards in hand.
Together we introduced the BoD to the idea of using a Scrum board to track our work. We started by brainstorming ideas in two key categories supporting the club’s 2015 goal of Membership retention and growth. Our two categories are membership activities and building improvements. After creating quite a backlog for the club, we discussed priority, and arrived at a commitment to working on a subset of the backlog for the upcoming sprint. Our sprint cycle was easy to determine as there are two meetings a month at the club, providing approximately 2 weeks in between each meeting. Board members signed up for stories listed in the backlog to get us off and running. At our general membership meeting, the visual board with our sprint and “product” backlog were introduced to the club.
Being “Agile” is a way of thinking. Core ideas like transparency, prioritizing, and collaboration can be incorporated into our everyday lives. I often suggest using a visual board for household chores when I’m doing training. No more nagging your partner, or kids. Just keep a board with 3×5 cards or post-its to identify upcoming work. Identify priority, acceptance criteria, and limit your work in progress by identifying a sprint length (one – two weeks work well). This helps to keep from feeling overwhelmed. Everyone is happier knowing what is expected. I’ve tried this at home with good success which is what led me to suggesting this for our club.
In taking these same principles and applying them to our club, we’re able to benefit from being Agile. The club members are our customers. They get visibility and input into the work being done. Members can make suggestions for new work, and volunteer to help. The club’s budget helps identify what can be afforded, and expected ROI helps us prioritize. Our initial work is underway, and I look forward to seeing our long-term projects lead us to sustaining and even growing our membership.
A colleague recently reached out for suggestions to help a new client whose teams are having trouble adapting to using story points.
Here are 10 tips to keep in mind when helping teams in their transition:
Change the Language – Are We Estimating Effort or Estimating Size
Story points are intended to reflect relative size. And while they are loosely correlated to effort (e.g., the bigger something is, the more effort it takes to do it), they are not meant to represent a precise measure of effort.
If your teams are grappling with estimating-in-story-points, try changing your language to sizing-in-story-points. It’s a subtle difference for those of us familiar with the concepts, but can ease the transition for those new to it.
Create New Language – Stay Away from Numbers
Historically, we think of size in terms of how-long it will take to do it. Break that strong association by using a non-numeric, relative scale such as t-shirts, dogs, boats, planes, fruits, vegetables, candy, or planets.
Clarify Language – Are We Talking Effort or Duration
Let’s take a simple example…..I have a friend who can drive across country in 3 days by herself. It takes me a week. Assuming we’re taking the same route, and driving the same speeds, why is there a difference? It turns out that my friend can drive 12-13 hours a day with minimal stops. Whereas I start falling asleep after 2-3 hours and have to stop frequently. So it takes me longer (duration) to do the same amount of work (effort).
Duration is the time it takes to complete something from start to finish and is stated in “duration-units” such as hours, days, weeks, or months. Work (effort) is the amount of work required to complete something and is stated in “work-units” such as man-hours or man-days. Because these both have a “time” component, we often mingle them together inappropriately, causing problems if there’s not a clear, shared understanding.
For instance, when I estimate a task to be 40 hours, what I mean is “it will take me 40 man-hours to do this, if I have the information and decisions I need in a timely manner, if tools are available when I need them, and if I’m not working on anything else”. What others often hear is “it will take someone a week to do this”. I’m talking about effort; others are hearing duration.
The teams my colleague observed used the following definition when estimating their stories:
1 SP = 3-4 days
2 SP = 1 week
3 SP = 2 weeks
5 SP = 4 weeks
8 SP = 6 weeks
They are tracking actual hours worked on each story and are expecting that a 2-point story equates to a consistent number of hours. But their definition is expressed in duration-units rather than work-units, and the actual effort to complete a 2-point story can vary widely depending on whether one person can finish it in a week or it takes 4 people to complete it.
Don’t define story points in duration-units and expect it to correlate to effort.
Skip Estimation, Go Directly to Work
If your teams are thrashing because of estimation, then don’t estimate. Use commitment based-planning and have them track their story throughput rather than points or hours. As they become more comfortable with this, stories will begin to creep smaller and smaller naturally. Check out more about the #NoEstimates movement.
Compare to a Baseline
Have the team select a story that is representative of the type of work they do, assign a size to it, then compare all other stories relative to the baseline.
The more the team does what’s uncomfortable for them, the more practice they get, and the better they will get at it. Opt for shorter iteration lengths, as this will offer more opportunities to practice.
If teams are thrashing, there may be too many changes happening at once for them to absorb. We’re looking for the creativity and speed that comes from being on the edge of chaos, not in the middle of it.
Focus efforts on improving the ability to create vertical slices of value.
Once teams can craft valuable slices, focus on reducing the variability in story sizes rather than thrash about estimating. Strive for small stories using story-splitting techniques. Smaller slices are easier to size, easier to finish, make mistakes visible sooner, and allow for quicker feedback. Smaller stories also improve the flow of work.
As stories become small, uncertainty and dependencies decrease, and effort and duration can be good approximations of each other. A rule-of-thumb is a story should be small enough to be completed in less than 1/3 the length of your iteration, e.g., no longer than 3-4 days in a 2 week iteration. Mature teams will often have stories that take around one day, and all their stories are of similar size.
Remember – it’s the Conversation that’s Important
The magic about relative estimation is not in getting to an answer, but in the conversation that leads to shared understanding.
And…don’t Over-Stress the System
No matter what anyone thinks, pressuring a team to accept 800 hours of “planned” work when they only have 500 hours of capacity is not reasonable, and it will never work. Forget the “if you challenge them, they will rise to the occasion” call to arms. After a certain point, that’s just a bunch of malarkey.
As my grandma used to say, “You can’t get blood from a turnip”.
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.
When people see my business card or email signature, they sometimes question the letters beside my name: what do they mean,should they try to get them too, etc. One set of those letters seems to jump out a bit more as a question than others – the PMI-ACP. I think it’s because they see “PMI” and wonder what it’s about. I’ve even had some people ask if it’s misspelled. So, to clear the air, I’ll explain it…
The PMI-ACP is an Agile certification that is administered by PMI which signifies that you understand, and have experience in, implementing Agile methods. There is a combination of an exam and the project experience you have in Agile projects to acquire the certification.
If you are still a bit confused, the Project Management Institute is considered to be the go-to source for all things project related. As such, they are seen as the foremost authority on the processes that are used to deliver projects. Over the last 5 years or so, as Agile has become increasingly the favored way to deliver projects, the PMI has added Agile to their Project Management Book of Knowledge (PMBOK) and added the PMI-ACP certification.
So far this doesn’t sound like much of a big deal, right? Well, let’s see why it is…
As I mentioned, in the world of project management, the PMI is seen as the ‘governing body’ when it comes to ways to deliver projects. Anyone that works on any project knows there are rules that PMI has set forth on managing projects. Since the influx of projects using Agile processes, more and more project managers need to be apprised of the rules that change or the various ways that PMI has suggested instilling the Agile processes.
With the increase in Agile projects, there is a growing need for required guidance for these projects. Companies are looking to their project managers and team members to gain the knowledge and expertise to ensure successful projects.
By having Agile experience and taking the exam, you too can acquire your PMI-ACP so that you can show your fellow project managers and team members that you have the experience and knowledge to help lead Agile projects effectively and successfully!
In order to acquire your PMI-ACP, you first should acquire the required experience in Agile projects. PMI’s required number of hours is 1500 on Agile projects. This can be done using any of the Agile methods and on multiple projects.
In addition to the project experience, you will need 21 hours of Agile education, which you can gain in numerous ways, including the PMI-ACP Exam Prep.
After you have worked on Agile projects, then you will need to take the PMI-ACP exam. Now, most people get a little squeamish when talking about taking an exam, but I’m here to tell you not to worry! There are many ways to study for the exam so that you can breeze through it, but the easiest being to take a class that will prep you for the exam. Check out the PMI-ACP Exam Prep offered by CC Pace—it will give you an extra boost in your knowledge, your 21 hours of education, and some practice of taking an exam!
The PMI-ACP is seen differently by different people; some see it as just a set of letters while others see it as a way of exhibiting their knowledge of Agile processes, as accepted by PMI. Either way, it is something that will most definitely show your team you accept the Agile mindset and are embracing the shift that project management has taken to follow the Agile processes!
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.