Category archive

Agile Engineering - page 2

Twelve Awesome Interactive Facilitation Techniques for Agile Teams

in Agile/Agile Engineering/Product Management/Project Management

If you work with a team, and possibly, you are the Scrum Master or Lead or Product Owner, or just a Team Member trying to guide a conversation — then these interactive facilitation techniques are for you. But before we move on, let’s first get it out there that we may call these “Interactive Facilitation Techniques”, but they are really games. More specifically, games that help us at work. Using games — I mean interactive facilitation techniques — help us to effectively and easily facilitate discussions. Using these games to helps to drive good team behaviors (Blunt 1993) including cooperation, clarifying, inspiring, risk taking, harmonizing, and process checking. All the while, helping to overcome the destructive team behaviors of dominating, rushing, withdrawing, digressing, discounting, and blocking. That all being said, let’s get to it. The following list of games are those that I’ve personally used with teams that I see work really well and are easy to adapt. I’ve taken the liberty to group them by the team meetings where they make the most sense; however, as I previously said — they are easy to adapt and can be used for almost any activity.

General Brainstorming

Affinity Mapping – An oldie, but a goodie — this great way to collect, organize, and rationalize ideas — even large amounts of ideas. I’ve used this to help understand the objectives of meeting attendees and get everyone on the some page. Here’s a great a time-lapse video of a team using Affinity mapping to sort 500 pieces of customer feedback…

Dot Voting – Dot voting is a simple way to get a group of people to form consensus. This technique let’s everyone have a voice and it’s a quick and easy way to rank things. By the way, here’s a cool and FREE tool to do this with distributed teams … http://www.dotvoting.org

Pre-mortem – First off, let’s remember that words mean things and mortem is related to death. So I equate doing a pre-mortem to death planning including making your bucket list, understanding what things you should do to be health, and things to do to stay safe. The pre-mortem is a great risk management technique.

Discovery

Product BoxProduct Box – Also known as Vision Box, this is a great way to discover what customers think, a way to uncover expectations, and ultimately share – or gain a shared understanding of the product or project or release. I find the product box to be a great exercise for Release Planning and project chartering.

My Worst Nightmare – This is a great way to get into heads of the team and learn from their experiences, anxieties, and expectations. An easy way to express yourself, you use pictures. They say a picture is worth a thousand words and it’s true. I use this exercise to prime the pump on understanding objectives.

Spider Web – Another game from Innovation Games, Spider Web is a form of context diagramming, but it’s no the run-of-the-mill context diagramming. First, everyone get’s to draw, second — use pictures, and finally, no rules — lines can go from one item to another. You’ll find this a great game to understand information flows between people, systems, and organizations.

Requirements

Staple Yourself to Something – Have you ever found that getting started is the hardest thing to do? Well, this is the perfect game for you. This game involves mapping out processes, it helps to quickly get everyone on the same page as to how something should work. It helps with knowledge exchange, establishing process flow, and establishing a shared understanding.

Empathy Mapping – Establishing personas is a key activity at helping to understand our customers or the users of the systems we are building. This technique is a fast-and-easy way to do understand our users as a team. Even if you already understand your personas, let the team do this exercise and see what they discover.

Buy a Feature – Have you’ve ever been frustrated with stakeholders not being able to make prioritization decisions? Buy a Feature is an awesome way to help drive the discussions around prioritization. You may not land on the final ranking, but you will gain some awesome insight into what is important and where people are willing to negotiate.

White Elephant Sizing – This is the only way to estimate stories. Okay, not the only way, but it’s a good way. This game is a spin on the White Elephant gift exchange we do after the holidays. The values of this game are conversations and shared experiences of all the players. If you want to find a fast way to estimate, try this.

Retrospectives

SailboatSailboat and 4Ls – I’ve talked about both of these games before, and I play them regularly to help evaluate coaching sessions. I encourage folks to mix it up all the time with regards to retrospectives, and these two games are great ways to do it.

Learning Matrix – This one is from Diana Larson and Esther Derby’s Agile Retrospectives book. What I really like about it is that you find things to improve upon based on looking at what you are doing right. You review where things are going well and look at how applying what you are doing well to this things that are going wrong.

Check out the AgileBacon links page for sites that are all about Games that Work.

Behaviors and Culture Can Impair Creating Good Product

in Agile/Agile Engineering/Product Management/Project Management/Teams

When we think culture, we often think about nationality and or regional cultures. Culture is often a dinner discussion with my wife and friends, it’s great to reflect upon how our upbringing, surroundings, and maybe even our genetics drive our work habits, how we work with others, and how we see and work with authority. Culture is a difficult thing to work with because it’s engrained in us.

A few weeks ago, VersionOne released the 7th Annual State of Agile Survey. Within the survey, it is obvious that culture is the leading challenge to all aspects of agile adoptions and transformations. There were two questions within the survey that really highlighted the cultural challenges (note, I plucked out the key responses that impact culture – be sure to check out the full survey):

Concerns about Adoption

  • Lack of Upfront Planning – 34%
  • Loss of Management Control – 31%
  • Management Opposition – 27%
  • Dev Team Opposed to Change – 18%

Specific Organizational Failures Behind Agile Failures

  • Failure to integrate people – 34%
  • Failure to teach team-based culture – 28%

Prior to the survey being released, I already started making a list of those human behaviors and or cultural behaviors that I’ve seen impact the ability of an organization to build good software, let alone those behaviors that negatively impact an organization’s agile initiatives. Here’s my list:

  • Controlled manFear of Losing Control. This is primarily an individual fear; however, it can also be engrained in the organization. I’ve heard, “if I don’t put these controls on how the team works and if I’m not making decisions, when they screw up — I’m the one that is going to hang.” Of course, the idea of control being lost ultimately becomes a myth, because we generally see everyone’s engagement raise up a notch or two. Thus, resulting in more people being involved in making the decisions at the proper levels — hence scaling the organization.
  • Gate Keeper Culture. Often a subset or product of Fear of Losing Control, this is the manager or director who acts the liaison between his or her direct reports and the rest of the organization. I’ve seen and even lived in environments where all communications have to go up and down the ladder. Or, where in order to talk to someone on the “protected” team, you have to walk past the Gatekeeper and they then take the message or grant permission as long as they are part of the discussion.
  • Measurement of Success is Based upon “On Budget and On Time”. Many organizations, especially IT organizations live in the world where they try only be concerned with what they can control — and that is generally, “we deliver what was signed off and will do it based on a budget and set schedule.” Well, we fail to recognize that we should be measured based on the success of the product either in the marketplace or the usage internally. The funny part is when we time box and quit focusing on the when and who, and instead focus on the what — everyone is happier including the development teams.
  • “What’s My Role” Fear. This is the protectionist behavior where managers and or team members don’t see a fit for themselves or don’t find a fit for themselves as an agile transformation takes place. These team members or managers generally start start creating barriers to deflect blame while at the same time climbing to the roof-tops to shout out about the failures of the team and process. If others are looking at the right thing (e.g. product moving out successfully
  • Victim Mentality. Have you ever heard, “it’s always been that way and it’ll never change”? Well, this is the typical response for the person who either doesn’t want to deal with change — or they’ve been told “NO” so much, they just give up. Personally I used to be one of these people, then I learned quickly — if you don’t ask, you don’t get. And, if it is something that could have really positive results — isn’t it worth the risk?
  • photodune-3820842-young-superhero-sSuper Hero Culture. Now don’t get me wrong, I appreciate hard work and stepping up your game to make sure we succeed as a team. But constantly over committing and being let to overcommit constantly is not a good thing. I’ve also seen that individual who loves to be on a pedestal, thus when we start working more as a team — they’ll often be the person making back room deals to do more work or take on the clandestine project that our Scrum Master isn’t supposed to know about. Again, hard work is great — but we have to respect the concepts of sustainable pace, transparency, and “The Team”. Remember we regularly deliver value.
  • Us/Them Culture. This one is obvious, but it takes on a few forms including department silos, role based silos, and Ivory Tower silos. Department silos exist when we have complex solutions that require the integration of products from multiple departments and a bad or no rapport between the teams. Role based silos will generally exist in early agile adoptions where the value of diversification and cross-functional teams have not been visible yet. And Ivory Tower silos are those “I’m a Director” or “I’m the Product Manager” and you just do what I say — this never results in team work, unless the team is conspiring together to take down the Tower. If people talk about the managers in the organization as “The Suits”, then you might have some Ivory Tower silos and possibly going in the opposite direction.

What challenges, either culturally or behavioral, have you’ve experienced? I’m interested to here about those that not only impacted your agile implementation, but those that impacted delivery good product.

Steve Jobs on Innovation

in Agile/Agile Engineering

gty_steve_jobs2__dm_111006_wg

Sometimes when you innovate, you make mistakes. It is best to admit them quick, and get on with improving your other innovations.Steve Jobs

Hit and Run Build Breaker

in Agile Engineering/Humor

Funny parody on Real Men of Genius — Real Agile Genius!

[inline_media]
[/inline_media]

Common problem, someone checks in code at the end of the day and breaks the build.  Heck, at least there’s continuous integrations taking place 🙂

Thanks to my peeps at VersionOne for doing this one.  Jerry is an excellent actor, he would never leave with a broken build.

It’s Not a Bug, It’s a Feature

in Agile/Agile Engineering

featureI know everyone who has worked in or on or amongst a development team has heard the saying, “it’s not a bug, it’s a feature.” When said, it is usually followed by some laughter, sometimes remorseful laughter. Heck, you’ll even hear the users beat you to the punch when they say, “that’s a feature, not a bug – right?”

Ding. Ding. Ding. Mr. User, you are absolutely correct!

Anything that goes out the door is a feature of our product (or anything we release to our users is a feature). Now whether the feature improves the value of our product or service, or if it detracts from the value — they are all features. We chose to release our software — we may have known about the problem or we may have known that we did not test enough or we may not have had the awareness of a unique usage scenario – no matter what we chose to release and everything in the product is a feature. Couple the concept of releasing bugs in our code with the premises around technical and design debt, well now our heads are exploding as producers of software.

Now, you are probably saying, “yes Matt, we get that … but what’s your point?”

Well a lot of organizations struggle with the concept of balancing the amount of bugs (and technical debt) in the software that we address versus the amount of new features and enhancements that we add. We often find that stakeholder who is all about the sexy or the cool — looking for that differentiator that users want.  As a delivery team, we are quick to say to the stakeholder, “you don’t get it, users aren’t going to like this and it’s going to costs us more to fix later.” This statement is 100% correct. The stakeholder, who may have a case of “rabbit ears” responding to a big prospect need and he or she may not have visibility or understanding about the extent of the technical debt within the software.

So what do we do about it and how do we find balance?  There are four things that I’ve seen work really well:

1. Make all bugs and technical debt part of the backlog. I run into folks that will manage bugs in one system and stories (requirements) in another. They need to be together — remember a bug is a feature, it’s just a negative one. You can write the bug as a story. The bugs should be ranked and treated like any other member of the backlog.

qualitychart2. Create Metrics and make them BIG AND VISIBLE. A chart that demonstrates number of bugs by severity on a specific day is not too useful to communicate this problem. But, a chart that shows a trend over the last six months the # of bugs found with a corresponding chart series that shows # of support calls for the same period and with another line that shows % of maintenance renewals — well, now you have a powerful story. How about a chart for measuring quality that is based on the number of known bugs released / number of support calls? Or, similar to this the number of new features released / number of support calls. And, how about a simple number — the percentage of our total backlog that is associated with bugs and technical debt. I guarantee a high number will get someone’s attention. Make these charts part of your team’s information radiator, post them on the wall in the break room, or start making them part of that weekly project report.

3. Conduct frequent Extermination Hack Fests. Establish one day an iteration as a bug extermination day or maybe ever three iterations, use multiple days for this activity. This is not just about having an hardening sprint, it is about allowing the engineers (architects, testers, and developers) to team up and knock out bugs with the only consideration that once you start working on a bug, it must be fixed or an approach designed to fix, by the end of the Extermination period.

4. Align resolving bugs and technical debt with strategic goals. Almost all companies have goals associated with customer satisfaction, or growing our footprint within our existing customer base, or establishing market leadership. These goals are not achieved by putting out crappy product. By leveraging the metrics above, value can be placed and impact measured of resolving bugs and paying back debt to achieve strategic goals. Be sure to measure improvements and investment against the goals as it surrounds bugs, and make it known when the team has an Extermination Hack Fest that resolves 15 customer found bugs which will improve our positioning on customers paying ongoing maintenance.

These are the four I’ve seen.  What have you used to get over the tug-of-war between new stuff vs. bugs?

Go to Top