Come to the Science Fair

in Product Management/Teams by

Remember that thing we folks that practice Agile call the Agile Manifesto.  You know the thing that where 17 smart folks got together and came up with a set of four values and twelve principles to help guide and shape the behaviors of those involved in software development.  Everyone might not be able to rattle off the principles, but most of us understand and appreciate the common sense of the four values.  At the core of all the Agile Manifesto values is a well maintained relationship between the delivery team and the customer (or Product Owner).  And this is where challenges have emerged and often things start falling down.  Here’s a common scenario that often plays out:

An organization starts making a shift to use an agile related process, let’s say Scrum.  They train the delivery team and the product owner, then kick it off with a team or two.  Everyone starts to work and they start seeing productivity gains right away.  And the teams are seeing vast improvements in communications and building products that customers like.  The organization then says — let’s have a few more teams start drinking from the Agile fountain.  Things are going well, but what starts happening is that during this scaling process — people start competing for meeting rooms during the sprint planning and review cycles, and the product owner’s time quickly becomes a constraint. Thus, teams start alternating their sprint schedules to deal with the room/resource issue and the product owner spends less time with all teams and seems to only focus on those teams that work on things that are not doing well or they like.

Now you are asking, what’s the problem?  Well, one of the best things that you’ll find when you start working in small incremental delivery cycles is that the teams form a rhythm (or cadence).  This helps for predictability that helps the organization in planning and more importantly, helps the team members in planning their lives.  Most people like repetitiveness and everyone is habitual (or at least most folks involved in software development), so by having multiple teams on different rhythms — organizations lose the natural state of “steadiness” that comes with shared cadence.

The other big problem with the scenario above is that the face time and feedback with the customer (or product owner) is critical to having success with all four of the agile values.  When teams start realizing that time with the product owner is being a challenge, they tend to simply give the product owner a pass on attending any of the iteration planning and or review — and they just ask for his or her time for stories and acceptance criteria.  This means that they lose out on the critical feedback that comes out during the reviews and demos.

Does this sound similar?  If so, here are some ways to help overcome these common time constraints that appear when you start scaling out agile.

  • Introduce a Gap.  If you are using an iterative approach, introduce a gap between your iterations.  The idea is to get everyone on the same iteration schedule and rhythm and by adding the gap, you’ll give time for folks to juggle room schedules and stakeholder time to ensure participation.  During the gap, the team will have time to properly plan the  upcoming iteration, work on a design/research spike, and or work on an item from the team’s technical wish list backlog.  The gap also can afford the team a quick breath and might also be an easy period to squeeze in some personal business time.
  • Go Short.  This may seem to be non-sense; however, if you are using an iterative process then trying working in shorter cycles.  Although it takes some adjustment, shorter cycles reduce the time it takes to iteration plan and review.  The end result is a tighter focus and that focus is generally on what is needed next.  Similarly, move to a lean or continuous flow process (give this a read to learn more).
  • Lunch-and-Collaborate.  Schedule meetings around lunch and, of course, have food.  Lunch is generally less formal and can be perfect for brainstorming, story workshops, demos, and team building.  Although team members some times need a break from work, most team members don’t mind meeting when food is involved 🙂
  • Record Your Demos.  A meeting that you don’t want to miss out on getting feedback is the demo; however, this is a meeting that for some reason the product owner and other key stakeholders will often miss.  This meeting is not only about showing off and having the team get some positive feedback — it is more about just getting feedback.  Try recording the demo.  Make the video less than 10 minutes, don’t worry about it being Oscar quality, just get it done and sent out to all those that can give input.  Solicit feedback within 24-hours of sending out the video, re-enforce the need for the feedback and participation.   In addition to the value of getting feedback from the stakeholders, the recorded demos are great timeline artifacts that can be used for retrospectives.
  • sciencefairConduct a Science Fair.  Often when scaling agile, there will be a product owner that works with multiple teams and making time for reviews and demos for all teams around the same time is near impossible.  So to get around this, conduct a science fair — have teams assemble in a meeting room and demonstrate their latest accomplishments.  This is not only a fair for the product owner, but this is a great time for teams to get together and see what the other teams are up to.  This is an event that the whole organization can be a part of and it is a great way to get an organization excited about capabilities forth coming.

So if your teams have had some challenges with face-time with the customer, difficulty establishing a cadence, or you are just not getting valuable feedback — try one or all of the approaches above.  These approaches can not only improve the collaboration, but they can be fun and challenging which will show up in improved team morale.

Reinvigorated Retrospectives

in Agile Engineering/Teams by

Have you these statements lately?

“Our retrospectives have dried up.”
“Why are we doing this?  We never do anything about it.”
“Uh, I don’t know – there’s nothing that we need to change.”

Well, this is not uncommon for agile teams to reach the point where their retrospectives become ineffective or the team members stop seeing value in the meeting.  In fact, this occurs with both newly formed teams that just haven’t grasped “Inspect and Adapt”, and mature agile teams that have either lost sight of the need for continuous improvement.  There are multiple reasons why retrospectives may be going south, but there’s three biggies that stand out in the crowd:

  • They’ve Become Monotonous.  Ok, so we’ve been asking the same three questions for the last six months – “What can we Start? What should we Stop? And, what should we continue?”  Although this format is tried-and-true, it takes on Borg-like repetitiveness – especially when it happens every two weeks.
  • No Actions Taken.  “That’s a great idea”, “We should do that”, “We need to make that happen”.  These are all great phrases often exuded during retrospectives and rarely are the items that these phrases share context with are implemented.  In fact, after the fourth retrospective performed – those actions and or issues mentioned in the first retrospective are re-digested.
  • Quiet Majority.  The quiet majority are those in the room that simply never speak up unless called upon.  These folks often are incredibly smart, but there are those in the room that tend to overpower and then those that have just given up on sharing their input because of the first two reasons identified above.

So now you are saying, “this is exactly what’s wrong with our retrospectives, but what should we do about it?”  Well, here are a couple great ideas that work:

Sailboat

sailboat3_webThere is a great game called Speedboat from The Innovation Games Company.  The original goal of Speedboat is to frame up a constructive manner by which customers can provide product feedback without spiraling into a complaint session.  The great thing is that this game can be used by teams for performing retrospectives.   This game has been transformed and adapted to Sailboat (first saw this posted here).  Here’s how it works:

  1. Assemble the team, you’ll need a whiteboard (or sheet of easel paper), sticky notes, and black pens.
  2. Draw an ocean, a sailboat floating on the ocean, and a couple anchors.  If you are the artistic type, feel free to add some flare (I like fish).
  3. Hand the pens and sticky notes to each of the attendees, and ask them to write down the bad things (or issues) and good things (or efficiencies) that have been discovered since the last retrospective.  Give everyone 5-10 minutes to write down their ideas, thoughts, and or opinions – encourage the team to participate.
  4. After everyone is complete, put the sticky notes on the sailboat – the good things represent wind in the sails and the bad things represent the anchors that slow the boat.
  5. Once the sticky notes have been placed, have the team organize them into themes or simply groups of like items (e.g. issues surrounding quality).  Eliminate duplicates and consolidate where possible.  Within each theme, rank the different sticky notes.
  6. Now the team should discuss each top item and identify issues that need to be worked and or stories to add to the backlog.

4Ls

The 4L’s is a retrospective technique put forth by Mary Gorman and Ellen Gottesdiener.  Teams like this format in that it’s quick and forces all parties in the room to interact.   The 4L’s are: Liked, Learned, Lacked, and Longed For.  As you can see, the 4L’s give people a simple area to focus their thoughts that can easily be translated into issues and or stories for the backlog.  Here’s how it works (taken straight from Mary’s and Ellen’s Blog):

  1. Assemble the team, you’ll need four posters (easel paper), sticky notes, and black pens.
  2. Hang the four posters (easel paper) around the room and title the posters appropriately, one for each “L”.
  3. Ask the team members to individually write down what they Liked, Learned, Lacked, and Longed For since the last retrospective.  They should write down one per sticky note.  Give the team 5-10 minutes and ask them to put their sticky notes on the corresponding posters.
  4. Divide the team up into four subgroups and assign an “L” to each group.  They should read all the notes, consolidate and identify themes.
  5. Have each subgroup report on the themes – this means read out-loud and converse.
  6. As a team, decide how they might use the data.  For example, ask “How can we satisfy the “lacked” or “longed for” items?”  Identify issues that need to be worked and or stories to be added to the backlog.

Both the Sailboat game and the 4L’s encourage full team participation, they are fast and focused, and they can be fun.  No matter which technique you use for your retrospective, always remember a few key rules:

  • Focus on process not individuals.  If there are issues between individuals, have them work it out and if necessary – involve a 3rd party.
  • Involve everyone.  The approaches above help drive this; however, be sure folks are contributing and more importantly they feel their input is important.
  • Do something about it.  The items identified should be tracked and acted upon.

Please share your ideas and thoughts, retrospectives can and should be fun — and they are immensely valuable.

Where’s the Incompetence?

in Agile Engineering by

Scrum is no silver bullet, and that it does not bring out excellence, but exposes incompetence.
— Ken Schwaber

So this is a great quote and it really resonates with any organization that is implementing scrum.  What you will inevitably find while implementing scrum is that certain team members and more importantly team functions and or departments are just not able to get the job done, or simply incompetent.  Maybe incompetent is not the best choice of words, but what I’ve found is that those people or departments that are asked to do something different, maybe step-up, or simply be around — stick out quickly when they are not performing well.  Within larger organizations, it’s not too uncommon to have team members that are able to hide and do just enough to skate by — this doesn’t work well within Scrum teams.

Weak LinkThe analogy to the weakest link in the chain is a great one for understanding the impact of a person or team that is not strong enough or capable of delivering on commitments made.  Just like a chain where the sound links of the chain can absorb the stress for a period of time, eventually the weak link breaks, the chain fails, and repairs must be made.  With implementing scrum, the level of stress remains constant and steady; thus, in short period the weak links appear.  When they do, preventive action should be made promptly to keep the chain, I mean the team, from failing.

So, what can be done?  Here are a few ideas that may work for your team:

  • Process Training.  This one is a lay-up.  Sit down with the team member or department head(s) to discuss their level of understanding regarding the Scrum process, how agile changes impact them, and how they can benefit from being part of the changes.  Identify opportunities for core agile process training, tool training, or possible soft skill training.
  • Identify the Strengths.  Often when a team member or department is failing, it is because they are working outside their strengths.  This does not mean that you change the team member or departments responsibilities, but it does mean that you might consider identifying ways for the team member or department to get their commitments complete while leveraging what they do well.  I wrote a previous blog about Strengths Finder, this is a great exercise for all teams — this will help a team to self-organize to ensure everyone can be successful.
  • The Team Adjusts.  Since the Scrum Team is cross-functional, identify ways that the weaker team member can meet their commitments.  This may be through have a team member move from developing core functionality to assisting QA on building out a test harness or possibly a QA team member working on documentation.  Often, when a team member is not performing well, it often ruins their self-confidence and this lack of success will continue.  Find tasks that the team member can be successful, get them some small wins, and see if that improves their outlook and inevitably their ability to perform.
  • Make the Hard Decision.  It may come to a point where a team member is just not cutting it, or because of their inability to meet commitments — they are bringing down the rest of the team.  It may be time to for a significant change — and a need to release the team member.  This is often better for the team, the individual, and the organization.  It is a hard decision, but one that needs to be made.  Allowing a non-performing team member to continue with the team and not meet commitments sends the wrong message to the rest of the team, and the Product Owner will start questioning the leadership of the team.  If it is a department that is not performing, it may be time to face this head-on and escalate the need to get better performance from that department.

Technical Stories – How to Work Them

in Agile Engineering by

I was perusing some blogs and I came across a discussion regarding Technical Stories on Jack Milunsky’s AgileBuddy blog.  The focus of the blog is whether or not Technical Stories should be included in the Product Backlog.  Jack does a good job presenting both sides of the argument, and in the end leaves it up to the reader to assess their individual products/projects.

In my recent experience at a software company that produced infrastructure products, it was not unusual to negotiate technical stories into the sprint.  However, this was easy to do because we were producing an enterprise infrastructure product where the primary user story might be “As a B2B administrator, I need to support over 1MM 50Kbyte transactions per day so that I can support the business growth.”  We would then have subsequent stories and tasks that support building a test harness, securing/procuring hardware, and executing various tests.  In addition to technical stories that satisfy core needs of the product, we also maintained a separate backlog that was focused on those things that improve the quality, maintainability, and supportability of the product.  Our product team was not huge and we were often charged with working a large amount of level three support, so for every couple sprints we would rotate team members into the role of level three support.  They would then assist with customer issues as well as work our technical story backlog.

So, having technical stories worked for us; however, I can see how they can get in the way of focusing on getting a product out the door and gaining the value as early as possible.  I share Jack’s opinion — do what works for you, but here are some key points to remember when considering whether or not to include technical stories in the backlog.

  • Educate and keep your Product Manager/Owner in the loop when it comes to technical stories. Most of the time, technical requirements are embedded in user stories.  In some cases it makes sense to pull out these technical requirements as stories because they may increase the product value in the customer eyes.
  • Assess whether or not a technical story should actually be a task associated with a user story with clear business value.  In most cases, a technical story could be a task associated with delivering a user story.
  • Maintain a separate backlog to house technical stories.  These stories should be worked by dedicated team members or at least with some level of dedicated capacity.
  • Incorporate what someone might write up in a technical story into done criteria and or the story’s acceptance criteria.  For example, enhancing the continuous integration environment, incorporating functionality into the nightly automation cycle, or verifying the new functionality is properly installed.

Five FREE Applications Every Agile Team Member Should Have

in Resources by

Honestly, there’s nothing like another blog that provides a list of information that the author believes to be useful.  Well, this list is extremely useful and it’s short — only five items.  The following tools are free desktop applications that I’ve found to be extremely valuable working within an Agile team.  These tools aid in collaboration, improve organization, and help make you more productive.  Enough with the build up…

  • Jing from TechSmith (http://www.techsmith.com/jing/).  Jing allows you to easily capture and annotate screenshots that look professional.  The screenshots are very high-quality, yet small in file size.  You can easily select a region, the whole screen, or just a flexible area.  On top of images, Jing can capture up to a five minute video with voiceover using your microphone.  This is great for a quick tip on how to use an application or communicating how to recreate a bug to a remote team.  Jing maintains a history of all captures and TechSmith also hosts an online site – www.screencast.com – where you can stream your videos.
  • Evernote (http://www.evernote.com). I think everyone knows about Evernote and there really isn’t much more that needs to be said except that it is a great tool to capture and synchronize notes on different devices.  Evernote has applications that can run on Mac, Windows, iPad, iPhone, Android, Win7 — you name it.  On top of this, their web interface is extremely effective and they have an ability to OCR even my sloppy handwriting sent from my iPad.
  • Freemind (http://freemind.sourceforge.net/wiki/index.php/Main_Page).  Mind mapping and brainstorming is not a lost art, and it is easily done with Freemind.  Freemind allows you to easily capture discussions and organize them.  Whether you are in the midst of a Release planning workshop or a Sprint Planning meeting, or laying out a wiki design — Freemind does it all.  It has great portability to other mind mapping software packages, as well as the output can be pushed out in outline mode.
  • iSpring Free (http://www.ispringfree.com/).  iSpring Free is a PowerPoint to Flash converter.  This means it will easily publish a presentation as a Flash movie on the internet or you companies intranet.  This is invaluable for sharing information with remote teams as well as training new team members.
  • Skype(http://www.skype.com).  It goes without saying, face-to-face communications are preferred over email, IM, or even the phone.  Skype does a great job at voice-over-IP calls and video calls.  With their latest versions, it does group video calling and it allows for screen sharing (instead of video).  It does all this free if the other callers are using Skype.  This is invaluable if you have remote team members or telecommuting.

These five free tools are great for facilitating communications, gathering ideas, and organizing your work.  I couldn’t do without these tools and once you start using them, I’m sure you’ll agree.  What free tools do you use?

Go to Top