Skip to content

Feed aggregator

Managing Your Macbook with Ansible

For a long time I’ve been a big believer in Infrastructure as Code and I have always wanted to use configuration management to provision my personal workstation and keep it constantly updated to an expected state. Boxen was one of the first tools I saw in this space and it even seemed like it might be comfortable since I was using Puppet at the time. However I never really had a lot of luck with it and the original aim of Boxen was actually lost on us at Zapier since we engineered a very nice docker-compose based setup that lets anyone begin running and hacking on zapier locally constrained by the time it takes to download the docker images for the first time.

That being said when we began transitioning from Puppet to Ansible last year and I naturally started using it locally to kind of whet my appetite a bit. Here’s a brief run down of how I’m currently using Ansible to manage my laptop and some notes on where to go next.

Getting Started

There are several guides out there on getting Ansible installed, the most authoritative being the instructions right on Ansible’s website. I won’t repeat those well written steps here.

Once that’s all done let’s run ansible --version and verify we’re running Ansible 2.0.1.0 or above. If you’re visiting from the future then I will have to say that I am really unsure if this blog post will work with 3.0.0 or whatever release is out then. Keep in mind this post is written in 2016. 🙂

First up we’ll create a very simple Ansible playbook that just prints a hello world message to the console to ensure we have everything configured correctly.

Place this in a project directory (I name mine “personal-dev-laptop”) and run ansible-playbook main.yml. If all is configured correctly you’ll see a playbook run that executes a task that prints out “Hello World” to the console.

Homebrew

The most important piece to a provisioning system is the package management and Ansible is no different. Homebrew is the go to on OSX and thankfully Ansible has a pretty decent homebrew module for managing the state of different Homebrew packages. Let’s dip our toes in by adding a task to ensure macvim is installed and at the latest version.

The nice benefit here is that each time we run Ansible macvim will automatically get updated to the latest available package. However if we want to ensure a package is simply installed but don’t want to upgrade each time we run we can set the state to `present`. After awhile if we’ve worked with vim and decided that it’s just not for us and we’d prefer to use emacs instead we could just set macvim’s state to absent and emacs state to latest.

Taking It Further
Sure we can just keep adding our own tasks to install roles, perhaps even using a with_items iterator to include a big list of them but sooner or later we’re going to be duplicating a lot of work someone else has done. Which is a good time to introduce third party roles installed via ansible galaxy. There are most likely several good roles out there but my favorite so far is geerlinguy.homebrew. I usually put a requirements yaml file in the main root of my project with the module I want to use and the version I want to lock in.

Now to install this third party role we’ll run ansible-galaxy install -p vendor -r requirements.yaml. The -p switch will install it to a local directory named vendor so we don’t clobber the global include path and we can add that directory to our project’s .gitignore so that it isn’t stored in git. We also add an ansible.cfg to specify the role path for third party roles we’ll be using.

Now we also update our main.yaml to include a few changes. Firstly we want to include the new role we just imported and then we move the packages we want to install as variables that the homebrew role will utilize.

This time we’ll run with the -K switch since this role also ensures that homebrew is installed and will require sudo access to do so. Now I know what you’re thinking… you’re thinking “James is trying to hack my box!” and quickly closing your browser tab. Obviously you should never provide sudo without giving the source code a look over and the most important pieces will be the main task file and meta file where there could be dependent roles. After careful inspection we decide all is good and run ansible-playbook -K main.yml. Congratulations, you now have Spotify and iterm2 installed!

One small improvement to make before we move on is to extract these variables that are specifically for homebrew to their own var file. While it might seem silly now, sooner or later we might be using many roles that utilize many different variables and mixing them will lead to a lot of confusion. I personally like to name the variable files after the role they’re used for as illustrated below.

Managing OSX Settings

You can do a lot of tweaking to how your OSX behaves by using the osx_defaults module to manage OSX Defaults. There’s a lot of opportunities here but I’ll just leave a quick and dirty example to set our preferred screensaver below.

You could possibly even go as far as using this to manage various applications you have installed and possibly even setting registration keys for those applications. I haven’t even gotten to that point yet either so I’m not covering it here.

Further Reading

Well I hope this was good for you… it was good for me and helped me flesh out some of my current setup. I’m still on my path to learning how to best utilize ansible to manage my development environment so there’s definitely more to learn that I’ll continue to share as time progresses. I’m also not ignorant of a few other projects that aim to make working with ansible to manage development environments easier and one I’ve been looking at is Battleschool.

You can find the completed work for this blog post on github at jamescarr/ansible-mac-demo.

Categories: Blogs

April Showers Bring May Flowers … and Events Galore!

BigVisible Solutions :: An Agile Company - Tue, 03/29/2016 - 19:00

Spring has sprung! And for SolutionsIQ that means one thing: conference season! 2016 is no different as we begin our circuit across the country to reconnect with industry thought leaders and Agilists of every walk of life. This year we’re partnering with so many organizations to bring our Agile Amped video podcast series to conference-goers and internauts all over the world! We are all about engaging with the Agile community and readers like you, so if you’re attending these events, come find us!

Mile High Agile: Elevating Agile Teams

April 4 – Denver, CO

SolutionsIQ is excited to be the Technology Sponsor for Mile High Agile this year. To generate some buzz and excitement for the latest and greatest Agile content in the industry, we invited Mile High Agile conference chair(wo)man Colleen Johnson to chat with Agile Amped about her experience and what to expect this year. Check out the vid, hosted by the incomparable Steve Smith:

 

 

Agile Amped will be onsite at Mile High Agile 2016 in Denver to capture all of the news and knowledge from industry thought leaders like Jurgen Appelo and Michael Feathers, both of whom are keynoting the event. SolutionsIQ’s own Steve Martin will be presenting his talk, “Managers and the Land of the Lost“, an interactive session aimed to help clarify Manager’s roles and responsibilities.

First Ever Agile Alliance Technical Conference!

April 7-9 – Raleigh, NC

Our roots are in software development. That’s why we had to jump on board for Agile Alliance’s first technical conference. We are proud to be sponsoring this event (as well as Agile2016 later this year, of course). We will be podcasting straight to you from our new backyard! With our new colleagues and friends from Davisbase Consulting joining us, we’re glad to have more opportunities to connect and expand our outreach from our new headquarters in North Carolina!

Global Scrum Gathering

April 18-20 – Orlando, FL

SolutionsIQ is excited to have five separate presentations at this year’s Global Scrum Gathering in Orlando! Check ’em out!

Subscribe to Agile Amped!

April is just the beginning of a whole season of conferences and events for us, so be sure to check back often for updates. To get Agile Amped podcasts delivered to your inbox as soon as they’re available, subscribe below!

The post April Showers Bring May Flowers … and Events Galore! appeared first on SolutionsIQ.

Categories: Companies

Sprint Day Checklist

Agile Game Development - Tue, 03/29/2016 - 18:05


I'm often asked about how other teams organize their sprints.  Below is an example calendar and checklist (click on the image) one team used to review, retrospect and plan their sprints effectively.
Categories: Blogs

The Ultimate Tester

Xebia Blog - Tue, 03/29/2016 - 17:14
   
Categories: Companies

Doing a retrospective when you can’t get the team to meet?

Ben Linders - Tue, 03/29/2016 - 16:12
Over the years I've had some situations where I couldn't get a team to come together in a retrospective to meet and reflect on the sprint. I've seen two different kinds of reasons for this. One was that a team wasn't convinced that agile was suitable for them, so they questioned doing agile retrospectives. The other situation was that the team believed in agile and Scrum and wanted to do a retrospective, but was looking for an alternative solution where they would not have to meet physically. Something that also a dispersed team would consider when travelling isn't an option. Let's explore how you can recognize these situations and deal with them. Continue reading →
Categories: Blogs

Certified LeSS Practitioner with Craig Larman

Learn more about transforming people, process and culture with the Real Agility Program

In just a few weeks we will be hosting Craig Larman here in Toronto as he facilitates the first-ever-in-Canada Certified Large Scale Scrum Practitioner training!  Large Scale Scrum (LeSS) is about de-scaling.  In simple terms, this is about using Scrum to make the best possible use of the creativity, problem-solving and innovation abilities of large numbers of people, rather than getting them stuck in bureaucracy and management overhead.

Here are the details of this unique learning event:

  • Date and Time: April 11-13 (3 Days), 2016 – 9am to 6pm all three days
  • Location: Courtyard by Marriott Downtown Toronto, 475 Yonge St. Phone: 416-924-0611
  • Price: $3990.00 / person (that’s in Canadian Dollars – super great deal if you are coming from the US!)

Check out the full agenda and register here.

Here are some quotes from previous attendees:

“It was inspiring to discuss Large-Scale Scrum with Craig Larman. The content of the course was top-notch.” – Steve Alexander

“The delivery was outstanding and the supporting material vast and detailed.” – Simone Zecchi

“The best course I have ever been on. Totally blown away.” – Simon Powers

Certified Less Practitioner BadgeToronto is a great place to visit (I know many of our Dear Readers are from the United States) – don’t hesitate to consider coming in for a weekend as well as the course!

Register now! (Goes to our BERTEIG / World Mindware learning event registration site.)

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Certified LeSS Practitioner with Craig Larman appeared first on Agile Advice.

Categories: Blogs

Scaling Agility Without Killing Agility

Agile Management Blog - VersionOne - Tue, 03/29/2016 - 14:30

Scaling Agility Arlen Blog

Frameworks for scaling agile methods have exploded in variety and popularity over the past few years: Scaled Agile Framework® (SAFe®), LeSS, and DAD are a few prominent examples. A common facet of these methods is the delineation of Portfolio, Program, and Team layers, with the idea of allowing goals at the executive level to be effectively communicated and driven through groups of teams.

The growth of scaling patterns has had significant effects, notably driving adoption and interest in areas where agile methods have historically encountered skepticism, such as government agencies and some large organizations. But not all is peaches and cream, as companies like mine which have helped organizations employ these methods have seen time and again. Based on these experiences, I offer the following guidelines for those considering the adoption of agile scaling frameworks.

  1. Get the team right first. Fundamental to all agile methods is the idea of autonomy at lower levels, such as a team in Scrum/XP, or a group of aligned individuals in Kanban. The ownership that this drives keeps teams more engaged and interested, while also speeding the process of evaluating and executing decisions. Our coaches have often noticed that introducing hierarchies early on can dramatically impede the ability of teams to decide, flex, and adapt to local circumstances, hence limiting the organization’s overall agility. Ensure that teams are able to make decisions and deliver locally before linking them in large hierarchies.
  2. Keep hierarchies as flat as possible. Layers of approvals slow decisionmaking, which hampers organizational agility. They also tend to slow delivery, and limit local innovation.  However, it is often the case that scaling methods are introduced largely with the idea of limiting organizational disruption, and hence they can provide an excuse for avoiding deeper (and often needed) organizational redesign. Consider how you might break an organization into smaller autonomous units before introducing multi-layered hierarchical planning processes.
  3. Pay attention to infrastructure and tooling. While perhaps the majority of agility focuses on the human element, the technology that underlies the process is just as critical when dealing with software delivery. The recent DevOps movement echoes the early agile method Extreme Programming by emphasizing the critical need to automate basic delivery capabilities through techniques like continuous integration, test driven development, and build automation, to the greater end of dissolving dependent silos. Absent this sophistication, teams find themselves still dependent on one another and external testing/release groups, once again defeating the local speed and flexibility that define agility. Scaling before addressing tooling can hurt organizations by allowing them to retain lengthy release cycles and dependent specialized teams, whereas short time boxes force better delivery capabilities.
  4. Release often to learn. Patterns like SAFe’s Agile Release Train can have some great effects by aligning historically separatist business-oriented silos such as Sales, Marketing, and Finance with their technology partners in Development and Operations. However, release cycles often end up settling on one-three month cycles. While there is nothing inherently wrong with this, it is of course possible (and often desirable) in many environments to deliver much more rapidly than that.There are two core purposes for releasing software in agile methods: to learn and to profit.  These must be considered separately. Constrained availability releases are generally meant to drive feedback at scale, like giving software to a field testing group or doing gradual rollout of new functionality through live A/B testing. This helps us understand what features are used most often, where glitches occur and so forth, and hence drive subsequent planning cycles. These should happen very frequently, on the order of days and weeks, and should not be constrained by higher-level planning cycles.Typically we have a higher bar for full-scale production release, which can also be driven or constrained by customer demand cycles. This can happen less often, as seems appropriate based upon market and customer cycles, but should not hamstring the ability to do small, quick releases for the purpose of learning.
  5. Ensure that information flows up, not just down. Building on the point above, much of the reason why agile methods encourage rapid releases is to ensure smarter, more empirical data-based planning, as opposed to the typical “guess what the customer wants then build it for months” approach we’ve seen historically. However, this requires that information garnered from user testing is rapidly received, understood and acted upon. In general, hierarchies dampen or eliminate the ability for such granular information to travel back up the chain and influence decision-makers.Some of my best agile business stories came from projects that were canceled or dramatically altered based upon information that was unavailable during initial planning, but that rapidly became available as ground truth became apparent from user and system behavior in the wild. If this information had been suppressed in the interest of avoiding disruption of some higher order, millions would have been lost in building the wrong thing. This isn’t an impossible problem to solve, but it requires curiosity and flexibility at higher organizational levels, and a clear strategy for ensuring that team-level data is considered properly during planning cycles.

Agile scaling methods have clearly filled a demand void, and they have introduced many tools and patterns that have been observed to work in certain environments. However, not every company or situation is the same, and hence no one method is likely to work the same way for everyone. One must remember that such methods are essentially toolboxes, so understand your goals before picking your tools, and keep in mind that true agility will never be so simple as adopting a methodology.

Lithespeed is a VersionOne premier partner. You can learn more about Arlen Bankston at www.lithespeed.com.

 

The post Scaling Agility Without Killing Agility appeared first on The Agile Management Blog.

Categories: Companies

Pattern: Testable Screens

Matteo Vaccari - Tue, 03/29/2016 - 13:44

When you are developing a complex application, be it web, mobile or whatever, it’s useful to be able to launch any screen immediately and independently from the rest of the system. By “screen” I mean a web page, an Android activity, a Swing component, or whatever it is called in the UI technology that you are using. For instance, in an ecommerce application, I would like to be able to immediately show the “thank you for your purchase” page, without going through logging in, adding an item to the cart and paying.

The benefits of this simple idea are many:

  1. You can easily demo user stories that are related to that screen
  2. You can quickly test UI changes
  3. You can debug things related to that page
  4. You can spike variations
  5. The design of the screen is cleaner and less expensive to maintain.

Unfortunately, teams are often not able to do this, because screens are tightly coupled to the rest of the application. For instance, in Javascript single-page applications, it would be good to be able to launch a view without having to start a server. Often this is not possible, because the view is tightly coupled to the Ajax code that gets the data from the server, that the view needs to function.

The way out of this problem is to decouple the screen from its data sources. In a web application, I would launch a screen by going to a debug page that allows me to set up some test data, and then launch the page. For instance:

Untitled 2

Note that the form starts pre-populated with default data, so that I can launch the desired screen with a single click.

Making screens decoupled from their data sources does, in my opinion, generally improve the design of the application. Making things more testable has a general positive impact on quality.

Categories: Blogs

How To Get Valuable Time Back: Part 1

Leading Agile - Mike Cottmeyer - Tue, 03/29/2016 - 12:30

Recently, I’ve been swamped with meetings.  I’m not talking Portfolio Planning, Release Planning, or even Sprint Planning meetings. I’m talking a lot of in-the-weeds type meetings.  After I walk out of some, I realize I could have been informed of the outcomes and action items and that would have been good enough. I didn’t need to sit through the whole damn thing.  There are times everyone walks out an hour later, are looking around, and are asking how to get that valuable time back.  It got me thinking, I need to write about this!  Then, as I started writing, I realized that this was either going to be a seriously long long-form blog post or I was going to have to write a few parts to it.  Being the bloggy-blog type, I vote for short form and write a series.

The Scenario

You arrive to the office at 8am on a Monday, only to realize you are late for a meeting someone on Friday after 5pm scheduled.  You’re not in the office 5 minutes and you’re already behind schedule.  What the hell!?  How does this happen?  You look at your calendar. You have back-to-back-to-back meetings all day Monday and Tuesday.  When are you supposed to actually do your work?  Given the current conditions, you’re going to need to catch up on things before or after work. This sucks!

The Problem

You have become a meeting hoarder.  That’s right.  At any moment, A&E is going to show up at the office and start filming an episode about you.  In this episode, they follow you around the office.  They confront you and the addiction of accepting too many meeting invites.  Of course this is ridiculous but you really do need some practical strategies to deal with this problem and get back on the track.

Meetings are supposed to be about the exchange of information.  Unfortunately, they are wildly inefficient and offer limited value.  For the most part, they are waste of our time.  Nobody wants to listen to you go on and on about how many meetings you have, now that you’re becoming a bottleneck in getting things done.

To start, I’m going to bucket meetings into 3 categories.

  1. Non value added but it is necessary.
  2. Non value added but it is NOT necessary.
  3. Value added.

I see very view meetings offer direct value to the customer.  Most meetings a non value added but we don’t have a sufficient method to exchange the information so we settle for the meeting.  It’s necessary.

Going forward, assume most meetings don’t add value and you should make them prove their worth to you.

The Solutions

In this post, I’m going to give you a strategy to begin controlling the volume of meeting invitations coming into your calendar. First, stop accepting meeting invites for meetings that are less than a full day away.  If someone invites you to a meeting at 5pm on Monday for a meeting at 9am Tuesday, they are being disrespectful of your time.

Set Limits

You may have a standard eight hour work day but the reality is that only half of that day is likely to be productive.  With that assumption, you should guarantee you have 4 hours of productivity. If you don’t, your day will be taken up with meetings, responding to email, browsing the Internet and related activities.  Block out 4 hours a day on your calendar for actual work. Make the events private.

Tip: Schedule your most important, high value tasks in the morning, before you get worn out from your current meetings

Turn On Your Email Auto-Responder

Until you can get your meeting addition under control, I recommend you begin using your email autoresponder.  I actually did this several years back, after reading The 4-Hour Work Week with very good results. When someone sends you an email or meeting invite, they automatically get an email from you (with the assumption that you have NOT read their invite).  This will buy you time to focus on real work and not just respond impulsively to the request.

Let’s look at a basic template

Greetings,
Due to high workload and too many meeting invites, I am currently 
checking and responding twice daily at 12:00 P.M. and 4:00 P.M.
If you require urgent assistance (please ensure it is urgent) that 
cannot wait until either 12:00 P.M. or 4:00 P.M., please contact 
me via phone at 555-876-5309.

All meeting invites will require 24 hour notice. Though I appreciate 
the invitation, sending me a meeting invite does not mean I will 
be accepting your invitation.
Thank you for understanding this move to more efficiency and 
effectiveness. It helps me accomplish more to serve you better.
Sincerely,
[Your name]
Conclusion

I can guarantee this is going to help, at least a little.  The more we can slow down the influx of meetings, the more we can assess the value of them and decide if we really need to accept them or not.  The autoresponder will put people on notice and inform them that your time is valuable but that you’re not being unreasonable.  If this gets you out of 1 meeting, won’t it be worth it?  I know it will do better than that.  Try it and let me know your results.

In my next post, I’ll write about how to triage your meeting requests, so you can begin spending more time doing real work and less going to meetings.

The post How To Get Valuable Time Back: Part 1 appeared first on LeadingAgile.

Categories: Blogs

How To Get Valuable Time Back: Part 1

Leading Agile - Mike Cottmeyer - Tue, 03/29/2016 - 12:30

Recently, I’ve been swamped with meetings.  I’m not talking Portfolio Planning, Release Planning, or even Sprint Planning meetings. I’m talking a lot of in-the-weeds type meetings.  After I walk out of some, I realize I could have been informed of the outcomes and action items and that would have been good enough. I didn’t need to sit through the whole damn thing.  There are times everyone walks out an hour later, are looking around, and are asking how to get that valuable time back.  It got me thinking, I need to write about this!  Then, as I started writing, I realized that this was either going to be a seriously long long-form blog post or I was going to have to write a few parts to it.  Being the bloggy-blog type, I vote for short form and write a series.

The Scenario

You arrive to the office at 8am on a Monday, only to realize you are late for a meeting someone on Friday after 5pm scheduled.  You’re not in the office 5 minutes and you’re already behind schedule.  What the hell!?  How does this happen?  You look at your calendar. You have back-to-back-to-back meetings all day Monday and Tuesday.  When are you supposed to actually do your work?  Given the current conditions, you’re going to need to catch up on things before or after work. This sucks!

The Problem

You have become a meeting hoarder.  That’s right.  At any moment, A&E is going to show up at the office and start filming an episode about you.  In this episode, they follow you around the office.  They confront you and the addiction of accepting too many meeting invites.  Of course this is ridiculous but you really do need some practical strategies to deal with this problem and get back on the track.

Meetings are supposed to be about the exchange of information.  Unfortunately, they are wildly inefficient and offer limited value.  For the most part, they are waste of our time.  Nobody wants to listen to you go on and on about how many meetings you have, now that you’re becoming a bottleneck in getting things done.

To start, I’m going to bucket meetings into 3 categories.

  1. Non value added but it is necessary.
  2. Non value added but it is NOT necessary.
  3. Value added.

I see very view meetings offer direct value to the customer.  Most meetings a non value added but we don’t have a sufficient method to exchange the information so we settle for the meeting.  It’s necessary.

Going forward, assume most meetings don’t add value and you should make them prove their worth to you.

The Solutions

In this post, I’m going to give you a strategy to begin controlling the volume of meeting invitations coming into your calendar. First, stop accepting meeting invites for meetings that are less than a full day away.  If someone invites you to a meeting at 5pm on Monday for a meeting at 9am Tuesday, they are being disrespectful of your time.

Set Limits

You may have a standard eight hour work day but the reality is that only half of that day is likely to be productive.  With that assumption, you should guarantee you have 4 hours of productivity. If you don’t, your day will be taken up with meetings, responding to email, browsing the Internet and related activities.  Block out 4 hours a day on your calendar for actual work. Make the events private.

Tip: Schedule your most important, high value tasks in the morning, before you get worn out from your current meetings

Turn On Your Email Auto-Responder

Until you can get your meeting addition under control, I recommend you begin using your email autoresponder.  I actually did this several years back, after reading The 4-Hour Work Week with very good results. When someone sends you an email or meeting invite, they automatically get an email from you (with the assumption that you have NOT read their invite).  This will buy you time to focus on real work and not just respond impulsively to the request.

Let’s look at a basic template

Greetings,
Due to high workload and too many meeting invites, I am currently 
checking and responding twice daily at 12:00 P.M. and 4:00 P.M.
If you require urgent assistance (please ensure it is urgent) that 
cannot wait until either 12:00 P.M. or 4:00 P.M., please contact 
me via phone at 555-876-5309.

All meeting invites will require 24 hour notice. Though I appreciate 
the invitation, sending me a meeting invite does not mean I will 
be accepting your invitation.
Thank you for understanding this move to more efficiency and 
effectiveness. It helps me accomplish more to serve you better.
Sincerely,
[Your name]
Conclusion

I can guarantee this is going to help, at least a little.  The more we can slow down the influx of meetings, the more we can assess the value of them and decide if we really need to accept them or not.  The autoresponder will put people on notice and inform them that your time is valuable but that you’re not being unreasonable.  If this gets you out of 1 meeting, won’t it be worth it?  I know it will do better than that.  Try it and let me know your results.

In my next post, I’ll write about how to triage your meeting requests, so you can begin spending more time doing real work and less going to meetings.

The post How To Get Valuable Time Back: Part 1 appeared first on LeadingAgile.

Categories: Blogs

Agile Manchester, Manchester, UK, May 11-13 2016

Scrum Expert - Tue, 03/29/2016 - 12:00
Agile Manchester is a two-day conference focused on Agile software development and Scrum project management. Participants can get knowledge and experience in a practical and peer-based learning context. In the agenda of the Agile Manchester conference you can find topics like “When emulating ‘Scaling Agile @Spotify’ goes awry”, “It doesn’t always have to be scrum”, “Bridging the communication gap, fast”, “The Lego requirements document”, “Keeping code agile”, “Integrating Creatives into Agile Teams”, “Moving away from Legacy code with BDD”, “Lessons learned in developing an agile architecture to reward our customers”, “Navigating Politics in Agile/Lean Initiatives”, “Evolution and Revolution: Making Change Happen”, “Agile: It’s not just about the development team”, “User Story Mapping for Fun and Profit”, “How to fail at Lean UX”, “The Agile User Experience”. Web site: http://agilemanchester.net/ Location for the Agile Manchester conference: thestudio, 51 Lever St, Manchester M1 1FN, United Kingdom
Categories: Communities

Principles of Effective Story Writing: The Pivotal Labs Way

Pivotal Tracker Blog - Mon, 03/28/2016 - 18:59

1-8kiD5IgprKNNqQljCjY4GA

Different teams across projects and companies have different styles of story writing. Ultimately, it is up to you and the team to figure out what is most effective given the goals and context of the project. However, the core principles that guide our story writing here at Pivotal Labs can be used regardless of style or variation in either process or syntax. While the differing views on the “best way” to write stories can make it difficult to determine the most effective approach, there are a few core principles that guide our story writing. In this post, we’ll explore the three most common types of stories that you can create in Pivotal Tracker and the core principles that inform how we write stories.

Story Writing: Guiding Principles

First and foremost, stories are placeholders for further conversations and context on conversations already had. We write stories to address a feature, bug, or chore, and then we discuss those stories—usually with our engineering team—to surface any lack of clarity or concern around delivering the story in question. Because of this, stories do not need to include every little detail, but should be a reminder of what was talked about and include everything at a high level.

It is also important to remember that stories should state the what, not the how (e.g., “Improve search response by 15 seconds” vs. “Do not perform a full-table indexing on every database update”). Stories are not meant to be technically prescriptive; that is, they do not need to specify any information on how exactly your engineering team could implement the functionality in question. Stories clarify the reason for the functionality and what specifically that functionality is.

All stories should follow the INVEST model:

INVEST

Different Types of Stories 

1-uyTfG2GtI5zNUwZHS536Cg

Features/User Stories: Feature stories are designed to explain the who, what, and why of the smallest incremental feature that can be added to a product that delivers user value. Feature stories are pointed by the development team and are estimated by complexity rather than by the time it will take to complete the feature. They are written from the user’s perspective and act as lightweight requirements documentation for a development team. Following the INVEST model, they should be independent and create clear value to the user. For example, each button should be added in conjunction with a feature instead of having a story that creates a row of buttons that are not connected to features. While features and user stories are often used interchangeably, for the sake of clarity—and to be consistent with Tracker’s naming conventions —we will refer to this kind of story only as a feature story throughout the rest of this post.

Feature stories should include several things:

  • Title: The title should be short, descriptive, and include the specific user/persona. For example, the user/persona should either be the specific type of user (e.g., editor) or the persona name (e.g., Jill) rather than just “user.” This also works for users that are not people but systems (e.g., “Purchasing API”).
  • Business case: Who wants the functionality, why, and to what end? This is incorporated so that everyone on the team understands why the feature is being added. If you cannot think of a reason, then it’s worth reassessing if the feature should be included. The business case also allows others on the team to think if there is a better user experience than the one provided.
  • Acceptance criteria: This defines what you will walk through to make sure that the story is completed. Developers working on the story should also walk through the acceptance criteria before delivering. At Pivotal, our beginning template for acceptance criteria is written in the Gherkin language. The Gherkin language was originally created for Cucumber, a Ruby testing suite, and is meant to “enforce firm, unambiguous requirements … and a script for automated testing.” Keep in mind that good feature stories should not, however, be prescriptive in implementation details.The syntax is as follows: GIVEN [necessary context] WHEN [action] THEN [reaction]. Sometimes it helps to walk backwards to determine your GIVEN (examples to follow). If you find yourself writing multiple “and”s in the acceptance criteria, that is a smell test that indicates you should split the story into two or more.
  • Notes: Include additional information needed for the story, such as design notes (which might point out changes to mocks) or developer notes (which might provide insight that could help developers deliver the story).
  • Resources: Add mocks, wireframes, user flows, links, and other assets to help deliver the feature story.
  • Labels: This includes epics (larger overarching features), build #s, users, etc. These are used most effectively to help group the stories together.

1-qm1KkZC1qlg4hwPX9_07FQ

Bugs: A bug is a defect in a feature that has already been accepted, regardless of when it was accepted. You should not use bugs to detail new features and functionality (e.g., “Price should be non-negative” or “Login button doesn’t work”). Bugs are directly related to features that have already been delivered and provide no new user value, which is why they do not have points. The other reason they do not have points is that bugs can be impossible to estimate and could take 30 seconds or 30 days to resolve.

Bugs should include this information:

  • Title: This should be short and descriptive.
  • Description: What is currently happening? What should be happening?
  • Instructions: Outline the steps to reproduce it.
  • Resources: Include screenshots and other assets to help explain/show the bug.

1-t2xuh7W88tS7Mbmi9XUCrw

Chores: A chore is a story that is necessary but provides no direct, obvious value to the user (e.g., “Setup new domain and wildcard SSL certificate to create test environments” or “Evaluate tools for system troubleshooting”). Chores can represent technical debt and/or points of dependency on other teams. Chores are not estimated (i.e., pointed), as they do not contribute user value directly. This means that if a chore feels like it provides user value then it should be incorporated into a feature story. For example, if you are using an analytics service, the additional complexity of the service setup should be taken into account in the first analytics feature story, rather than separated out as a chore.

Chores should include this information:

  • Title: This should be short and descriptive.
  • Description: Why is it needed? Does it help the team go faster or is it a dependency that could cause problems in the codebase if it’s not done?
  • Resources: Including instructions, additional context, or other assets that help execute the chore.

User and Bug Story Templates

The templates below are a great starting point for writing feature stories and bugs. We haven’t included a template for chores as they vary significantly, but we have provided examples of chores at the end of the post. These templates have been iterated on over the years to provide consistency, clarity, and simplicity. For easy access, we copy and paste them into the Icebox with a title of, “Cheat Sheet: Story Template—Reference When Writing Feature Stories” and “Cheat Sheet: Bug Template—Reference When Writing Bugs.”

Feature Story Template [copy & paste version]

feature story template

Bug Template [copy & paste version]

bug template

Conclusion

We have no doubt that as you become comfortable with story writing, you will formulate your own style that works best for your team or project and undoubtedly move away from the basic templates that we have provided. To that end, we’ve included below what we consider to be examples of great stories. As you’ll see, while they vary in style and syntax, they exemplify the core principles that we’ve highlighted in this post.

Examples of Well-Written Stories

Feature Stories

Using a persona name for a consumer-facing product

feature stories

Using a position name instead of persona name in an internal tool

position name

Bug

bug

Chores

chores

0-OOjUazGYzekiGi6E

This article was co-written by Ryan Jones (Product Manager) and Pablo Schuhmacher (Product Manager).

The post Principles of Effective Story Writing: The Pivotal Labs Way appeared first on Pivotal Tracker.

Categories: Companies

Bureaucratic tests

Matteo Vaccari - Mon, 03/28/2016 - 18:00

The TDD cycle should be fast! We should be able to repeat the red-green-refactor cycle every few minutes. This means that we should work in very small steps. Kent Beck in fact is always talking about “baby steps.” So we should learn how to make progress towards our goal in very small steps, each one taking us a little bit further. Great! How do we do that?

Example 1: Testing that “it’s an object”

In the quest for “small steps”, I sometimes see recommendations that we write things like these:

it("should be an object", function() {
  assertThat(typeof chat.userController === 'object')
});

which, of course, we can pass by writing

chat.userController = {}

What is the next “baby step”?

it("should be a function", function() {
  assertThat(typeof chat.userController.login === 'function')
});

And, again, it’s very easy to make this pass.

chat.userController = { login: function() {} }

I think these are not the right kind of “baby steps”. These tests give us very little value.

Where is the value in a test? In my view, a test gives you two kinds of value:

  1. Verification value, where I get assurance that the code does what I expect. This is the tester’s perspective.
  2. Design feedback, where I get information on the quality of my design. And this is the programmers’s perspective.

I think that in the previous two tests, we didn’t get any verification value, as all we were checking is the behaviour of the typeof operator. And we didn’t get any design feedback either. We checked that we have an object with a method; this does not mean much, because any problem can be solved with objects and methods. It’s a bit like judging a book by checking that it contains written words. What matters is what the words mean. In the case of software, what matters is what the objects do.

Example 2: Testing UI structure

Another example: there are tutorials that suggest that we test an Android’s app UI with tests like this one:

public void testMessageGravity() throws Exception {
  TextView myMessage = 
    (TextView) getActivity().findViewById(R.id.myMessage);
  assertEquals(Gravity.CENTER, myMessage.getGravity());
}

Which, of course, can be made to pass by adding one line to a UI XML file:

<TextView
  android:id="@+id/myMessage"
  android:gravity="center"
/>

What have we learned from this test? Not much, I’m afraid.

Example 3: Testing a listener

This last example is sometimes seen in GUI/MVC code. We are developing a screen of some sort, and we try to make progress towards the goal of “when I click this button, something interesting happens.” So we write something like this:

@Test
public void buttonShouldBeConnectedToAction() {
    assertEquals(button.getActionListeners().length, 1);
    assertTrue(button.getActionListeners()[0] 
                 instanceof ActionThatDoesSomething);
}

Once again, this test does not give us much value.

Bureaucracy

The above tests are all examples of what Keith Braithwaithe calls “pseudo-TDD”:

  1. Think of a solution
  2. Imagine a bunch of classes and functions that you just know you’ll need to implement (1)
  3. Write some tests that assert the existence of (2)
  4. [… go read Keith’s article for the rest of his thoughts on the subject.]

In all of the above examples, we start by thinking of a line of production code that we want to write. Then we write a test that asserts that that line of code exists. This test does nothing but give us permission to write that line of code: it’s just bureaucracy!

Then we write the line of code, and the test passes. What have we accomplished? A false sense of progress; a false sense of “doing the right thing”. In the end, all we did was wasting time.

Sometimes I hear developers claim that they took longer to finish, because they had to write the tests. To me, this is nonsense: I write tests to go faster, not slower. Writing useless tests slows me down. If I feel that testing makes me slower, I should probably reconsider how I write those tests: I’m probably writing bureaucratic tests.

Valuable tests

Bureaucratic tests are about testing a bit of solution (that is, a bit of the implementation of a solution). Valuable test are about solving a little bit of the problem. Bureaucratic tests are usually testing structure; valuable tests are always about testing behaviour. The right way to do baby steps is to break down the problem in small bits (not the solution). If you want to do useful baby steps, start by writing a list of all the tests that you think you will need.

In Test-Driven Development: by Example, Kent Beck attacks the problem of implementing multi-currency money starting with this to-do list:

$5 + 10 CHF = $10 if rate is 2:1
$5 * 2 = $10

Note that these tests are nothing but small slices of the problem. In the course of developing the solution, many more tests are added to the list.

Now you are probably wonder what would I do, instead of the bureaucratic tests that I presented above. In each case, I would start with a simple example of what the software should do. What are the responsibilities of the userController? Start there. For instance:

it("logs in an existing user", function() {
  var user = { nickname: "pippo", password: "s3cr3t" }
  chat.userController.addUser user

  expect(chat.userController.login("pippo", "s3cr3t")).toBe(user)
});

In the case of the Android UI, I would probably test it by looking at it; the looks of the UI have no behaviour that I can test with logic. My test passes when the UI “looks OK”, and that I can only test by looking at it (see also Robert Martin’s opinion on when not to TDD). I suppose that some of it can be automated with snapshot testing, which is a variant of the “golden master” technique.

In the case of the GUI button listener, I would not test it directly. I would probably write an end-to-end test that proves that when I click the button, something interesting happens. I would probably also have more focused tests on the behaviour that is being invoked by the listener.

Conclusions

Breaking down a problem into baby steps means that we break in very small pieces the problem to solve, not the solution. Our tests should always speak about bits of the problem; that is, about things that the customer actually asked for. Sometimes we need to start by solving an arbitrarily simplified version of the original problem, like Kent Beck and Bill Wake do in this article I found enlightening; but it’s always about testing the problem, not the solution!

Categories: Blogs

Personal Empowerment All-Stars: Jack Canfield, Ken Blanchard, and Stephen Covey at Microsoft

J.D. Meier's Blog - Mon, 03/28/2016 - 17:44

“You can, you should, and if you’re brave enough to start, you will.”  — Stephen King

One of the best things at Microsoft is the chance to meet extraordinary people.

Jack Canfield, Ken Blanchard, and Stephen Covey are a few that top my list.

They are personal empowerment all-stars.

As I was re-writing my posts on lessons learned from Jack Canfield, Ken Blanchard, and Stephen Covey, I noticed what they share in common.

What do Jack Canfield, Ken Blanchard and Stephen Covey have in common?

Their work has a heavy emphasis on personal-empowerment, positivity, and people.

I thought it would be interesting to write a narrative about lessons learned from each, to supplement my bullet point write ups.

Here we go …

Jack Canfield at Microsoft

Jack Canfield is all about taking full responsibility for everything that happens in your life.  And he starts with self-talk.  He says it’s not what people say or do, it’s what you say to yourself.  For example, it’s not what Jack says to Laura, it’s what Laura says to Laura.

From a personal empowerment standpoint, Jack reminds us that we have control over three responses: 1) what we say or do, 2) our thoughts, 3) the images in our head.  Jack is a big believer in the power of visualization and he reminds us that’s how athletes perform at greater levels — they see things in their minds, to guide what they can do with their bodies.

Jack shares a very simple formula for success.  Jack’s success formula is Event + Response = Outcome.  If you want to change the outcome, then change your response.  It sounds simple, but it’s empowering.

Jack Canfield also reminded us that we are the creative force in our life and to get out of victimism:

“You are not the victim of your circumstances–You are the creative force of your life.”

Grow your circle of influence and make tremendous impact.

Read more at Lessons Learned from Jack Canfield.

Ken Blanchard at Microsoft

Ken Blanchard is really about accentuating the positive.  So much of the world focuses on what’s wrong, but he wants to focus on what’s right, so we can do more of that.

Ken has an incremental model of leadership that starts with you and expands from there: you, your team, your organization.  The idea is that you can’t lead others effectively, if you can’t even lead yourself.

Ken’s model for leadership is really an adaptive model, that’s focused on the greater good, and it starts by helping everybody get an “A.”  Leaders that apply one style to all team members, aren’t very effective.  Ken suggests that leaders apply the right styles depending on what individuals need.  Ken’s 4 leadership styles are:

  1. Directive
  2. Coaching
  3. Supportive
  4. Delegating.

Perhaps, the most profound statement that Ken made is that “leadership is love.”  He said that leadership includes “loving your mission”, “loving your cusotmers”, “loving your people”, and “loving yourself — enough to get out of the way so others can be magnificent.”

Read more at Lessons Learned from Ken Blanchard.

Stephen Covey at Microsoft

Stephen Covey was really about personal effectiveness, realizing your potential, and leaving a legacy.

Covey really emphasized a whole-person approach: Body, Mind, Heart, Spirit.  His point was that if you take one of the four parts of your nature away, then you’re treating a person like a “thing” you control and manage.

Covey also emphasized the importance of a personal mission.  It gives meaning to your work and it helps you channel all of your efforts as you live and lead your legacy.  He also suggested writing your personal mission down and visualizing it to imprint it on your subconscious.

The other key to realizing your potential is finding your voice.  Use all of you, your best way, in your unique way, for your best results.  That’s how you differentiate and add value for yourself and others.

And, of course, Stephen Covey reminded us of the 7 Habits of Highly Effective People:

  1. Be proactive.
  2. Begin with the end in mind.
  3. Put first things first.
  4. Think win-win.
  5. Seek first to understand, then to be understood.
  6. Synergize.
  7. Sharpen the saw.

Habits 1,2,and 3 are the foundation for private victories and integrity.  Habits 4, 5, and 6 are the keys to public victories.

Read more at Lessons Learned from Stephen Covey.

All-in-all, I have to say that while individually each of these personal empowerment all-stars has great wisdom and insight for personal effectiveness, leadership, and success, they are actually “better together.”

Each day in the halls of Microsoft, I find myself reflecting on their one-liner reminders, whether it’s Covey’s “Put first things first,” or Canfield’s “You are the creative force of your life”, or Blanchard’s “None of us is as smart as all of us.”

You Might Also Like

How Tos for Personal Effectiveness at a Glance

Personal Effectiveness at Microsoft

Personal Effectiveness Toolbox

Categories: Blogs

It Just Got Easier to Get Important SAFe Content Updates

Agile Product Owner - Mon, 03/28/2016 - 17:23
Click to enlargeClick to enlarge

Hi Folks,

There is a continuous flow of SAFe information on the net. It comes fast, and in all forms: news, case studies, opinions, articles, videos, and more. We capture what we can on the SAFe blog, so that you can stay up to date.

But there is a lot of information there, so we’ve now made it easier for you to find out what’s most important via the the addition of a new “SAFe updates” feature on the Framework homepage,  You’ll see it at the top of the screen, just below the main menu. It allows you to quickly scan what we consider to be essential reading for SAFe practitioners engaged in a SAFe implementation. This is where new content will be developed, pointers to new guidance articles and more, and each post is open for comments so that we can get your feedback. This is how we develop SAFe, in full, public view. We need your input to keep SAFe safe.

The rest of SAFe news will continue as usual—see how it’s organized in the diagram pictured here—but for those of you who are implementing SAFe, you’ll want to keep an eye on the “SAFe updates” section so you can stay informed about the latest developments. And if you add value via comments, we’ll hope to capture that too.

Stay SAFe!

–Dean

 

Categories: Blogs

Dealing with Dead Letters and Poison Messages in RabbitMQ

Derick Bailey - new ThoughtStream - Mon, 03/28/2016 - 13:30

A question was asked on StackOverflow about handling dead letters in RabbitMQ. The core of the question is centered around how to handle what are known as “poison messages” – messages that are problematic and cannot be processed for some reason.

Dead letters

The person asking wants to know how to deal with these bad messages, when they have been sent to a dead-letter queue. The queue stacks up with messages while the code to handle them is fixed – but what happens when the fix is ready? How do you re-process the messages through the right queue and consumer?

The Original Question

TL;DR: I need to “replay” dead letter messages back into their original queues once I’ve fixed the consumer code that was originally causing the messages to be rejected.

I have configured the Dead Letter Exchange (DLX) for RabbitMQ and am successfully routing rejected messages to a dead letter queue. But now I want to look at the messages in the dead letter queue and try to decide what to do with each of them. Some (many?) of these messages should be replayed (requeued) to their original queues (available in the “x-death” headers) once the offending consumer code has been fixed. But how do I actually go about doing this? Should I write a one-off program that reads messages from the dead letter queue and allows me to specify a target queue to send them to? And what about searching the dead letter queue? What if I know that a message (let’s say which is encoded in JSON) has a certain attribute that I want to search for and replay? For example, I fix a defect which I know will allow message with PacketId: 1234 to successfully process now. I could also write a one-off program for this I suppose.

I certainly can’t be the first one to encounter these problems and I’m wondering if anyone else has already solved them. It seems like there should be some sort of Swiss Army Knife for this sort of thing. I did a pretty extensive search on Google and Stack Overflow but didn’t really come up with much. The closest thing I could find were shovels but that doesn’t really seem like the right tool for the job.

There’s a lot of text in the question, but it can be boiled down to a few simple things – summed up in the question’s own “TL;DR” at the start.

The TL;DR Answer

In the middle of the second paragraph, this person asks,

Should I write a one-off program that reads messages from the dead letter queue and allows me to specify a target queue to send them to?

Generally speaking, yes.

There are other options, depending on the exact scenario. However, there is no built-in poison message or dead-letter handling strategy in RabbitMQ. It provides the mechanism to recognize and isolate poison messages via dead-letter exchanges, but it does not give guidance or solutions on handling the messages one they are in the dead letter queue.

One Solution: Automatic Retry

Sometimes a message is dead lettered not because of your code or a problem with your system. For example, an external system may be down or unreachable. In cases like this, an automatic retry of a message can be a useful solution for a dead letter.

The best way to achieve this will vary with your needs, but a common solution is to set up a delay for the re-try. Using the delayed message exchange plugin as your dead letter exchange will allow you to set a timer on a message in the hopes that waiting for the service to come back up will be successful.

But, this would only automate the retries on an interval and you may not have fixed the problem before the retries happen.

The Needs Of The System

In the case of the question being asked, creating an app to handle the dead letters is likely the best way to go, for several reasons.

  • The need to examine messages individually and decide what to do with them
  • The need to find specific messages in a queue – which isn’t possible in RabbitMQ, directly
  • The need to wait for an unknown period of time, before retrying, while things are fixed

Each of these requirements are individually not difficult to do – but to do them from RabbitMQ, in an automated manner, may be difficult if not impossible. At least, it may not be possible all the time.

Examine Messages Individually

One of the stated needs is to look at messages in the dead letter queue and individually determine what should be done with them. There may be a lot of reasons for this – finding messages that have bad or missing data, identifying duplicates that can be thrown away, sending messages off for analysis to see what can be fixed or be done, etc. 

It’s possible to use a standard consumer for some of this work, provided the examination can be automated. 

For example, say you have previously fixed a bug and are dealing with a lot of messages that need to be re-processed. It may make sense to write a small app that reads the dead letters from the queue and re-publishes them to the original queue, assuming they meet some criteria. Messages that don’t meet the criteria could be sent to another queue for manual intervention (which would require it’s own app to read and work with the messages).

If you can automate the “examine messages individually” process, you should. But this is likely not possible early in a project’s life as the ability to do this typically means problems have already been solved and the solution can be automated. When you’re early in the life of an app, you’ll likely run into problems that don’t have a solution, yet, and you’ll need to manually sort through the messages to deal with them.

Find Message By Some Attribute

RabbitMQ is a true queue – first in, first out. You don’t get random access, seek or search in it’s queues. You get the next message in the queue, and that’s all you’ll ever get. Because of this, features like searching messages to look for certain ones, while ignoring others are not really possible. 

This means you’ll need a database to store the messages, and you’ll need to pull the messages out of the queue so they can be searched and matched correctly. Because you’re pulling the messages out of the queue, you’ll need to ensure you get all the header info from the message so that you can re-publish to the correct queue when the time comes.

But the time to re-publish messages is not always known.

Re-Publish At An Unknown Future Time

It may be ok to leave the messages stuck in the queue while you fix the problem. I’ve done this numerous times and with great success. Fix the problem, republish the code and the queue starts draining again. 

But this only works if you are dealing with a single message type in your queue. 

If you are dead-lettering multiple message types or messages from multiple consumer types, and sending them all to the same dead letter queue, you’re going to need a more intelligent way to handle the messages. 

Having an app that can read the dead letters and re-publish them when a user says to republish, will be necessary in some scenarios.

Not Inventing Anything

In the original question, a statement of this not being a unique problem appears:

I certainly can’t be the first one to encounter these problems and I’m wondering if anyone else has already solved them.

And certainly this person is not the first to have these problems!

There are many solutions to this problem, with only a few possible options listed here. There are even some off-the-shelf software solutions that have strategies and solutions for these problems baked in. I think NServiceBus (or the SaaS version of it) has this built in, and MassTransit has features for this as well.

There are certainly other people that have run into this, and have solved it in a myriad of ways. The availability of these features comes down to the library and language you are using, though.

Because of this, it often comes down to writing code to handle the dead letters. That code may require a database so you can search and select specific messages, get rid of some, etc. 

But whatever your language and library, you should automate the solution to a given problem. But until you have a working solution, you’ll likely need to build an app to handle your dead letter queue appropriately.

Categories: Blogs

Testing the Agile MBA

Agile Tools - Mon, 03/28/2016 - 07:12

man-person-hand-lens

“Research is formalized curiosity. It is poking and prying with a purpose.”

-Zora Neale Hurston

So as I thought about my earlier post on the idea of an Agile MBA, I realized that there is a whole lot that goes into putting together something like that. So before heading down that path, a guy might be well advised to check and see if there is any real interest in the idea before wasting a lot of energy on pursuing it further. So with that thought in mind, I created openagilemba.com.

The idea is simple, taken from the lean startup world. If you have an idea, put it out there and test whether or not there is a market for it. So I’m doing exactly that. Go check it out. I named it the “Open” Agile MBA because I’m not trying to sell anyone anything. What I have in mind is more of an open source MBA model. If we can assemble the resources, then anyone can use them. That’s kind of an exciting idea. It’s not new, there’s a NoPay MBA out there that is really cool and does something similar for a standard MBA.

So I’m starting with small, agile steps. Simply put up a web page and ask people if they are interested. If I get a few responses (feedback!), then I pursue it further, if it’s just crickets, then perhaps I tweak the idea and try again. I can’t wait to find out!


Filed under: Agile, Lean, MBA Tagged: AgileMBA, Lean Startup, Open Source, Testing
Categories: Blogs

Empty Customer Chairs – Illustrating the Absence of Customer Participation


Once upon a time, there was a company that said it was customer focused.  They used Agile methods to incrementally build software. At the end of an iteration, each team within the company would conduct a demo session.  The feedback from the demonstrations would be used to adapt the product toward what was deemed as customer value.  When the demo was investigated, it was learned that there were no actual customers or end-users in the demo. The question that may then be posed is if there are no customers in the demos, then what are the teams adapting too? 
What appears to be a challenge to some companies who say they are customer-focused or Agile, is how to successfully construct a functional demo.  The short answer is that customers or at least the end-users must attend the demo.  Of course this is more easily said than done.  The long answer is to establish a the Agile Customer Feedback Vision.  This vision is a strategy for identifying the right customers to attend, applying personas that represent the various customer groups, establishing feedback sessions throughout the work, and then motivating the customers to attend the feedback sessions. 
In the meantime, how do you highlight the problem of the missing customers?  Certainly those in the company understand that gaining customer feedback is important to the success of a product.  Even when providing companies with the mechanics of a customer feedback vision, customers are still found missing from the demos.  Why is that?  Maybe it's important to illustrate the obvious, that customers are indeed missing from the demos.    One way to illustrate the obvious to companies and their teams is by applying the Empty Customer Chairs technique.   The Empty Customer Chairs is a visual way to highlight the absence of customers at a demo of the product.  The technique is applied by having 3 chairs that represent the customer at a demonstration. If customers attend the demo, they fill the chairs.  If no customers attend the demo, then the chairs remain obviously empty.  If the demo is held virtually, then 3 virtual screens are designated to customers.  If no customers attend, then those 3 screens remain empty. 
It would be hoped that a company or team realizes the benefit of customer participation.   Until such time, this technique can help you illustrates the obvious lack of customer participation that may have the intent to motivate the filling of those seats. At the end of the day, it is all about delivering customer value and this is a technique that can help you highlight the importance of this value through the absence of the customer. 
Categories: Blogs

Two topics best avoided in retrospectives

thekua.com@work - Sun, 03/27/2016 - 16:51

When I introduce people to retrospectives I often am asked what topics should be covered and not covered as part of this. When I have asked this question of other people, I hear answers like “Everything should be open for discussion” or “No topic is ever taboo.”

Although I agree with the sentiment, I strongly disagree with the statements.

Photo from coltera's Flickr stream under the Creative Commons licencePhoto from coltera’s flickr stream under the Creative Commons licence

Yes, being able to discuss most topics openly as a team, particularly where there are different views is a sign of a healthy, collaborative team. Even then, I still believe there are two topics that teams should watch out for because I feel they do more harm than good.

1. Interpersonal conflict

Imagine yourself working with a team where two people suddenly start shouting at each other. You hear voices continue to escalate, maybe even watching someone storm off. An uncomfortable silence descends in the open team space as no one is quite sure how to react. Is this something you discuss as a team in the next retrospective?

Perhaps if the issue involves the entire team. When it involves two people where tension escalated too quickly over a single topic, it is more likely you need mediation and a facilitated conversation. A person wearing a leadership role (e.g. Project Manager, Line Manager, or Tech Lead) may be an ideal person with context to do that, but it may also be better to find a mediator who can get to each person’s interests and to find a way to both move forward and to start healing the relationship.

Although it will be impossible to ignore the topic in a retrospective, the focus should be on team expectations about behaviour, or identify ways the team can support each other better. It is unlikely you will solve, as a group, the conflict between the two people without making each of them very uncomfortable and unsafe.

behavioural issues for a single person

Just as you wouldn’t isolate two people and make the entire retrospective about them, teams must not “gang up” on a single person unless they feel safe to discuss the topic. If the entire team complains about what a single person is doing, the person is likely to feel targeted, isolated and potentially humiliated in front of their peers.

It may still be important to highlight issues impacting the entire team, but be careful that a retrospective does not become a witchhunt.

Where repeated, consistent behaviour needs to be addressed, a better solution is targeted one-to-one feedback.

Conclusion

Retrospectives are important practices for agile teams, but it is not a tool that will solve all problems. Retrospectives work well with other tools that offer better, more focused conversations for smaller groups such as mediation and one-to-one feedback.

What topics do you think should be avoided in retrospectives? Please leave a comment with your thoughts.

Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.