Improving Blogs

Scrum master woes

Jane Prusakova — Wed, 23 Sep 2015 23:02:00 +0000

The scrum master was genuinely upset:

-  Scrum is so hard. Engineers do not like it. They feel exposed.
-  Well, yes – Scrum calls for transparency, and that is a good thing. Engineers will learn to share.
-  But we have to do estimates. And then we have to deliver to those estimates. Then things happen. And engineers hate to do it, and then explain how a task that was estimated at 2 hours took three and a half.

It is easy to see why engineers do not like this process. Rapid churn of iterations calls for very frequent estimates – and regular inspections of why these estimates turned out to be not quite right. It is painful to be continuously wrong, and even more frustrating to have to defend tiny details of the complex minutiae that is software development.

What can the team, and the Scrum Master, do, to lessen the pain?

The scope of estimates is negotiated between the project manager or product owner, and the product team. Many a project manager would like correct, non-changing estimates provided on the first day of the project. Many a team would be perfectly happy to not estimate at all. Usually, neither gets exactly what she wants, but instead negotiates a compromise with the other side.

The scale of possible compromise solutions

The team does not provide any estimates. Project manager, with the help of the Scrum Master, makes educated guesses, based on their experience with the team and the project, when the backlog items will be completed. In this case the team may not share how it is breaking down the work, the progress it is making during the iteration, nor the problems it encounters. Priority of backlog items is established based on their value, and only project managers’ perception of the size and complexity of each item, since the team may not share its evaluation.

The team provides detailed estimates to project manager at each iteration, and works hard to deliver per estimated completion times. Project manager gets a full report of each working hour of the product team, and gets to control how the work is broken down and accomplished by the team. In this case the team may not be fully forthcoming about how long each tiny item will take, and pads the estimated schedule so that there is enough slack to deliver even if things go wrong. Even if everything goes fine, the team is more likely to deliver on a padded schedule and use the slack time to relax, rather than forge ahead. Even with seriously padded timeline, estimates are often too optimistic, in which case the team will be blamed for incorrect estimates, encouraging even more padding going forward. Detailed estimates take a lot of time and effort, and so does hiding the slack/padded time that the team puts into estimates. The team will be working harder, without a corresponding rise in productivity.

The team provides coarse-grained relative estimates, by sharing with the project manager how hard each item of work is expected to be. The expected delivery timeline can be deduced, but is not promised, so that the project manager shares in the uncertainty of software development. Still, the project manager can use that information to adjust priorities of various backlog items. The product team does not have to be defensive about not delivering per estimates, because no particular timeline is being promised. The mutual expectation is that most of the estimates will turn out to be wrong, but when the estimates are averaged over multiple backlog items and several iterations, they will provide valuable, actionable information to the team, the project manager, and the rest of the organization.

What are coarse-grained estimates?

It is helpful to classify pieces of work on a scale of Trivial, Small, Large, etc. Fewer options means coarser estimates. Using numbers (prime, Fibonacci, etc.) may encourage defining too fine-grain a division. Using hours or days creates a direct timeline, suggesting that a particular delivery date has been promised. Another option is to use anonymous units of complexity, and those are great if the team can in fact treat them as abstract units (and not convert units into timeline, as it often happens).

Having less-than-perfect estimates, and no timeline, requires and helps build trust between the team and the project manager. The team is held responsible for the average productivity, rather than each particular estimate. The project manager is asked to give up the illusion of full control over the project timeline and trust the team to deliver as best they can.

Scrum Master is tasked with negotiating the compromise, and holding both sides responsible for their respective contributions.

The Scrum Gauntlet of Debt

Ron Quartel — Mon, 21 Sep 2015 18:12:57 +0000

Overview:

A quick and easy demonstration/game to illustrate why an agile team needs to do refactoring and the related XP Practices in addition to Scrum. It never fails to create the A-HA moment for a team and team management as to why, when and how to do refactoring.

Learning Points:

Scrum without XP will lead to technical debt and ultimately a legacy system.

Timing: 30-40 minutes including prep and debrief

Requirements

Materials: Tools, supplies and environment

You will need an area/room where you can clear a game area we will call the gauntlet. Gauntlet area needs to be 15-30 feet long and 6-10 feet wide. Typically I find myself in a room where you just shove the tables and chairs out of the way to clear this space. Keep the chairs nearby as you will need them.

In addition to the space you will need :

Volunteers (7-12 volunteers)
Two opposing walls and two easels or use two easels in place of wall plus two more easels
Chairs (observers can give up theirs while watching if need be)
Sticky notes (small square size is better but any will work)
Flipchart (Sticky is best)
Blue tape
Something with a countdown timer (smartphone apps work)
Three surfaces for flipchart sheet. E.g. walls, whiteboard, easel
Marker pens to write on flipcharts (and whiteboard)

Preparation

Volunteers and Roles

You need 7-12 volunteers. Ask for volunteers with warning that it is a physical demonstration and there will be running. Do not volunteer unless comfortable with this.

Divide the volunteers into testers and developers using one of these formations depending on the number of volunteers

• 10 devs and 1 or 2 testers

• 8 devs and 1 or 2 testers

• 6 devs and 1 or 2 testers

Divide devs into two even groups

Have everyone in the room clear a space for the gauntlet and place one dev group at each end of the gauntlet in front of a To do/ To Test kanban board

To Do / To Test

Populate the TO DO portion of the board with sticky notes as shown.

You will need around 20.

(These empty notes represent a task or story.)

Place the tester(s) at the mid point of the gauntlet in front of the done board/flip chart/easel.

Done

Your gauntlet area should look something like this …

Gauntlet game area layout

Timer volunteer – (Can be the facilitator if no-one else volunteers). This person will need to have an app or device that has a 30 second countdown timer.

Explain to participants that this is a simulation. The goal is not to “win” and game the system. The goal is to mimic what real life looks like.

Instruct participants to act like a dysfunctional team and not communicate with each other (otherwise they start gaming the system).

They should all be in their locations as below :-

The Rules

An iteration lasts 30 seconds
Developers run to opposite wall, pick a story token (sticky note) from TODO and run back to their starting wall, placing the token in the TO TEST column
A Dev can only work on one story at a time
Testers wait by their Done board until they see stories ready to TEST and then run to (either) board, grab up to 3 stories (but no more than 3) and return them to their done board
Everyone must run (That is why they call it Sprinting!)
No collusion or working out a system. You are mimicking a dysfunctional team (Be sure to have explained this or else they game the system)
Each sprint (except for the first) you count the number of post-it notes in the done area(s) and that is the velocity for the sprint.
Make sure to run a sprint zero without measuring velocity. That is the practice sprint to ensure everyone understands the rules. (Velocity always goes up after this sprint so don’t measure it.)
BE CAREFUL!!! (Re-iterate and ask volunteers again if comfortable)

BE CAREFUL!

Health and safety
Don’t have anyone pregnant, wearing high heels or with physical disabilities that may cause risk to themselves or others in the volunteers
Make sure volunteers are comfortable with exercise otherwise switch out
Re-iterate to volunteers Safety First!
Be careful!!!

Start the Game!

Sprint 0 – Practice

Run this 30 second iteration with taking the velocity. Correct any misunderstanding and assumptions that anyone may have.

(There is another reason for running a practice sprint is because without doing so, the velocity for the next sprint will go up even if you put more obstacles in. The reason I believe is because once they understand the game, they get better at it. So give them a grace understanding sprint.)

Sprint 1 – Calibration

The goal of this sprint is to find out what their Scrum velocity is. Let them run the gauntlet with no obstacles. At the end record the velocity which is how many tasks are in the Done areas.

e.g. Sprint 1 – 13

During the sprint the facilitator can play the role of a pushy manager and shout at the team. See below for examples of things to shout.

Ask the team if they feel puffed out / exhausted. Ask if they think they can sustain this pace?

Point out that in scrum they call an iteration a sprint for a reason… (joke)

Reset the boards for the next sprint.

Sprint 2 – Introduce technical debt

Describe to the room that what they have just seen is what happens in scrum. Management want you to run as fast as you can and get features in.

But what is happening while you are introducing new features to the code base you are also introducing technical debt. For every story completed you left behind debt.

Ask the room if in their environment they have technical debt. (Yet to have a no come back to this question.)

Now grab chairs from the sidelines and place them randomly in the gauntlet area to represent the technical debt. Place them purposefully to make running the gauntlet difficult.

Re-iterate to the runners that this is a simulation and the goal isn’t to game the system and win. Re-iterate that they are simulating a dysfunctional team and are not to communicate with each other (to collude).

Double re-iterate safety! No jumping the chairs. Please be sensible and careful!!!

Now run the second sprint. Again take on the role of pushy manager and include in your taunts : -

why have things slowed down?
you developers are useless
why are your estimates wrong?
etc

Take the velocity of the second sprint.

e.g. Sprint 2 – 10

Note – it actually takes putting quite a few chairs in the gauntlet to impact velocity in this sprint. I usually put in 10-15.

Sprint 2a – Legacy system (but don’t run this sprint as it’s too dangerous)

Have the runners reset their boards for the next sprint.

While they do this – place more chairs in the gauntlet while explaining to the room “for every story you get done, you are adding more technical debt”.

Make the gauntlet almost impossible. Now speak to the room about this is how you create a legacy system. You leave debt behind on top of debt.

Point out to the managers in the room that this is what it is like for a developer. To come in and face a messy codebase and be expected to add value to the system every sprint without ever having time to clean it up.

Ask the room if the gauntlet is now representative of their codebase and running it representative of their job.

Ask them what they think will happen to velocity for this sprint. Ask them what they think will happen if they keep going forward in this way.

Do not run an iteration under these conditions – it is now too dangerous. You will break things (just as you break the code when you try to add new features to a legacy system).

Instead we are going to find a solution…

Sprint 3 – Introduce refactoring and find what their sustainable pace is

The new rule for this iteration is – refactoring.

For each story that you work on you are allowed to do some refactoring – cleaning up of the codebase. This is represented by being able to move one chair out of the gauntlet for each story you are working on.

You will also no longer run – but walk. We need to find a sustainable pace and we need to move more purposefully and carefully.

Walk, don’t run.

Go!

During this sprint the facilitator can call out management stressors like :-

who said they could refactor?
why are they pair programming?
what is this nonsense?
we are doomed if they work at this pace!
we don’t need refactoring, we need features!

At the end of the sprint record the velocity and have everyone return to their seats for the post exercise discussion.

Management Abuse to shout at game players

Faster!
I need more features!
What is wrong with this team?
Why are they so slow?
Why are your estimates all wrong?
More velocity!
Development monkeys!
Screw code practices – I need Features!
Stop that pair programming nonsense!
My last team was better than you guys
Don’t make me fire you
I should out source the lot of you
Run, run, run!
Lazy coders!
I’m paying you too much!
There’s going to be overtime!

Post Exercise Discussion

At this point your velocity will look something like :-

Sprint 1 – 14

Sprint 2 – 12

Sprint 3 – 8

Now talk about what the numbers mean.

Sprint one represents what happens when companies take on Scrum. They become excited about the ability to get things done quickly. Because Scrum does not include any technical practices the usual pattern is to ignore them but now the Product Owner and business is used to a certain cadence of delivery. What they don’t realize though is that it is not sustainable and they are incurring a debt with compounding interest. i.e Technical Debt

Sprint two represents what happens over time as the debt starts to build up. You are ignoring the agile principle (behind the Agile Manifesto) of :-

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

Sprint three represents Extreme Programming and sustainable pace. You are now writing code in a sustainable way where it is easy to add new features and the technical debt is kept in check. Refactoring is part of coding. You should not need to ask permission to do it, you must do it as part of writing code. But this may cause a change in your coding culture and processes. This is the next part of the discussion.

Code Entropy, Iterating toward Legacy, Technical Debt, Refactoring is not an Island, Extreme Programming

These are all distinct topics that are raised by the exercise and should be discussed. It would make this article a little too long if I include what to address to all of these here so I shall add links to blog articles as I write them. To start with however you can look at :-

Iterating Toward Legacy – Scrum’s Achilles Heel

Slideshare of this exercise presented at Agile 2015

Lack of women in technology industry starts early

Jane Prusakova — Tue, 15 Sep 2015 21:06:00 +0000

As a part of the wonderful HoustonTechFest, an annual community event for the technology industry, we got to have a very important conversation on diversity in our communities. A very small portion of software engineers are women. It is rather rare for women to enter, thrive, and build successful long-term careers in the technology industry.

During our panel discussion at the HoustonTechFest “BuildingSoftware Is A Team Sport: Women In Technology” we discussed the benefits of having both men and women participate and be successful in technology field. Participants talked about the problems for different ages and career stages, and what we as a community can do about it. We also looked at the societal biases, rooted far outside the technology industry, that keep men and women apart and less than successful professionally, and how each one of us can help our friends and colleagues lessen the effects of these biases.

As a technology professional, I observe these biases nearly every day. I work with many smart, successful, and open to diversity and true meritocracy men and women. I also interact with people who believe that women cannot be capable engineers.

Recently, I’ve come across a scary source of these biases. My toddler attends a wonderful daycare center – a loving, fun place where kids play, learn, and build their social skills through interacting with other kids and many excellent teachers. Yet, one day my child came home from daycare with this scary idea: “Girls are nice. Boys create messes. I do not like boys.” She went on to name girls who she likes, because they are girls, and boys who she does not like, since they are boys.

We have had several conversations as a family how boys and girls are both kids who play and learn together, how boys and girls can both be nice and fun. How it is OK to not like kids who are mean or angry, but it is not fair to not like or not play with a kid simply because he is a boy (or a girl, for that matter).

However, this is a tough message to deliver to a little kid. Just as tough as it is to convince grown up, professional men and women with extensive work and life experience, that both men and women can be smart, capable, innovative, and contribute greatly to the success of the industry, if given a chance.

The struggle continues. Please join us for our next discussion about successful diverse teams in technology.

Spreadsheet Craftsmanship

Dennis Somerville — Sat, 12 Sep 2015 02:13:27 +0000

Timing

30 minutes

Overview

You have inherited a spreadsheet from a coworker. The spreadsheet calculates the cost of consultants, given the following: number of contractors, hourly rate, number of hours per day, start date, and number of contract months. The spreadsheet is currently DEFECT FREE.

Preparation

You will need to download the Excel spreadsheet

Overview of the Game

A facilitator will be distributing the requirements one at a time. Once you finish making the required changes, you will be given another requirement. Please make the changes quickly so we can meet our company’s deadlines.

Round 1

Please make the requested changes on the “good” worksheet. The round is over when a) you finish all of the requirements, or b) the changes are getting too hard to make.

Round 2

Repeat this process on the “better” version worksheet. Start from the beginning with the first requirement.

Round 3

Repeat the process on the “best” version worksheet. Again, start from the beginning with the first requirement.

Learning Points

Why was it easier to make changes on the best or better versions? Why?
Which version will allow us to deliver the most business value? Why?
Which version did you enjoy working with the most?
When you modified the “best” version, did you follow the best practices of named ranges, calculation formulas, etc., or did you just start hacking away at the formula? Why?
Calculation cells are like “methods”
Names ranges are like “variables”
Using calculation cells and named ranges make the formula more readable and allows you to focus on one small problem at a time

Discussion and Facilitation Guidance

Defects are “external quality”, readability/maintainability is “internal quality”
Pressure is a source of low internal quality
Low internal quality puts our future success at risk

Link to Game

http://densom.blogspot.com/2015/01/demonstrating-software-craftsmanship-to.html

The Bicycle Game

Christo Martens — Wed, 19 Aug 2015 14:02:00 +0000

In one of my projects I developed a retrospective technique that is the combination several other techniques. This technique I called the ‘bicycle game’ because of the result: a nice bicycle.

Goal

This game has two main goals:

To let the participants think not only from their own perspective but also from an external perspective
To let the participants do a deep dive in finding the real cause of a problem

Timing

The game can be finished in about 60 minutes.

Materials

The Bicycle game makes use of :

Sticky notes (3 colors) and pens
Two pieces of paper (flip-over, brown paper)

Instructions

Preparation

The agile coach prepares the game by identifying some (6 to 8)characteristics, that he wants the team’s feedback on. This might well be the shared team values that the team has defined during project start.

Prepare a spreadsheet (like Microsoft Excel), containing the criteria the number of participants and columns that calculate the minimum, maximum and average of the rates, and that plots these values in a circular graph.

Duplicate this worksheet, and be finally creative in combining both graphs into a nice bicycle showing the average circles as wheels.

Execution – Information gathering

Start the game by asking the team to stand up.

The Agile Coach draws a star on a paper one ax per selected characteristic.
The Agile Coach asks each team member to rate his personal feeling regarding each characteristic on a scale of 0 to 5
The Agile Coach draws a circle like curve that connects the maxima and minima
This will end in a team radar.

The Agile Coach draws the same star on the second paper one (ax per selected characteristic).
The Agile Coach asks each team member to rate the feeling of some one the team is cooperating with regarding each characteristic on a scale of 0 to 5
The Agile Coach draws a circle like curve that connects the maxima and minima
This will end in a second team radar.

Execution – Deep dive into causes

The Agile Coach shows the ideal bicycle, with almost round wheels to the team
The Agile Coach shows the team created bicycle, like the one below
The Agile Coach asks the team to write down for themselves the causes of this so unpleasant riding bicycle on orange sticky notes
The team sticks the notes on the related axis of both team radar
The team members discuss and group their notes
The Agile Coach asks the to write down the basic causes on yellow notes
The Agile Coach asks the to write down a proposed solution on green notes
The team sticks the notes on the related axis of both team radar
The team members discuss and group their notes

Note: Other colors will fit as well.

Execution – pick actions

The team members eventually decide on the best actions to take in the next sprint.

Learning points

Of course the learning points of this game depends on the characteristics that are discussed. However, a very nice thing is that the participants look to their project form out an outside in perspective and that the participants have experienced not to stop thinking when they have found a cause for a problem as there might be a bigger cause as well.

This game was originally published on: AgilePMandCoaching.blogspot.nl

Think about your posture on your next interview – TED Talk

Brandon — Mon, 17 Aug 2015 20:53:47 +0000

Might be a good idea to do a “power pose” before your next interview

Amy Cuddy’s research on body language reveals that we can change other people’s perceptions — and even our own body chemistry — simply by changing body positions.

watch here – TED TALK

Why you should listen

Amy Cuddy wasn’t supposed to become a successful scientist. In fact, she wasn’t even supposed to finish her undergraduate degree. Early in her college career, Cuddy suffered a severe head injury in a car accident, and doctors said she would struggle to fully regain her mental capacity and finish her undergraduate degree.

But she proved them wrong. Today, Cuddy is a professor and researcher at Harvard Business School, where she studies how nonverbal behavior and snap judgments affect people from the classroom to the boardroom. And her training as a classical dancer (another skill she regained after her injury) is evident in her fascinating work on “power posing” — how your body position influences others and even your own brain.

What others say

“Using a few simple tweaks to body language, Harvard researcher Amy Cuddy discovers ways to help people become more powerful.” — TIME Game Changers, March 19, 2012

Make your code reviews Agile

Jane Prusakova — Sun, 16 Aug 2015 12:00:00 +0000

When discussing dealing with technical debt, fragile and buggy code base, and improving quality of the technical community, code reviews are a popular suggestion. Code reviews sound wonderful in theory: a junior or simply not-so-good programmer presents his work for review to an experienced grander-than-thou colleague, receives excellent suggestions within one hour, and another hour later all suggestions are implemented and the code transforms from nasty to near-perfect.

Enter reality. Thorough review of non-trivial code takes a long time. It is becoming increasingly harder to do a quality review as the time needed for the review increases. The pressure to provide a quality review suggests that more time is needed, and more time spent in review leads to poorer reviews, creating a downward spiral leading to deadlock.

Team dynamics are also affected. Giving a small number of reviewers the authority to dictate changes in work they are barely familiar with, without much feedback on the outcome of those changes, reinforces the bad habits of the reviewers and further entrenches their biases into the codebase. People required to accept suggestions without a possibility of challenge or feedback soon start to despise the reviews, the reviewers, and the suggestions. Neither reviewers nor authors feel responsible for the quality of the end results: reviewers because they only spent a little time reviewing, and authors because they were forced to make changes against their judgement.

So, are code reviews doomed to fail?

For code reviews to be a successful code-quality tool, consider an Agile approach. Make code reviews small and nimble, and have the entire team in charge of making, accepting and implementing generated suggestions.

That means everybody reviews everybody else’s code, in tiny little chunks. No formal meeting should be required. Everybody is invited and encouraged to generate improvement suggestions on all other team member’s work – and expected to defend their ideas. There is no separation of roles into those who critique, and those who are being critiqued. All team members are required to ask for and work with peer feedback.

One Word Retrospective Game

Lauren Thomas — Fri, 14 Aug 2015 15:36:57 +0000

Post-its and pens is all you need!

WORD UP!

Each Team Members place a word on the board that highlights the sprint for them

Team Plays Sprint Dictionary

One team member selects a word of the board
Everyone BUT the person who put it up on the board discusses what they think the team member meant by the word
The thoughts are captured
When everyone has said all the want to say, the team member who put the word up shares what they meant by the word

Team Discussion

After the team member shares their thoughts , the team discusses
What did we just hear from everyone?
What can we glean from what we heard?
Are there some underlying feelings, issues, etc. we need to dig deeper into?

UNO MAS?

Team Members places another word on the board that highlights the sprint for them if they have them

repeat team discussion

Lost For Words?

When there is nothing left to say (no more words)
Where do we put them?

Bury It- we want to leave behind and not take forward
Pack it – we want to put in our backpack and take with us
DEV Server – We need to work on this, put on our backlog

Retrospective darts

Lauren Thomas — Fri, 14 Aug 2015 15:19:25 +0000

There are three rounds of darts

Each team member gets 3 darts

Each team member places their first dart on the board and explains what they are scoring and why they scored it in the way they did

The next team member places their dart and so on

Then the second dart and then the third dart

Three Rounds with Three Darts:
Round One – Process
Round Two – Product
Round Three – Team

you have a triple line which means this was really great

You have a double line which means it really good

You have numbers 1 -20. One being the lowest value and 20 being the highest value.

outer bull – was a wOW! but got an idea of how we can still improve it with a little tweak

Inner bull – We hit it! it was the best we could do!

After each round the team analyzes the results

What have we learned and what are we still struggling with?

What do we need to continue to do?

What do we need to put in the backlog for agile improvements?

Retrospective Dart Game.pdf (1015 KB)

GeekMeet Networking, Aug 12th @ The Londoner

Brandon — Mon, 03 Aug 2015 15:29:41 +0000

Join GeekMeet on August 12th to network with other IT professionals in Dallas.
It’s important to build & maintain your professional network. Your network can be there for you when you need a job, a reference, a new contract, ideas on how to hone your skills, and so much more.

Date: August 12th
Place: The Londoner
Address:
14930 Midway Road
Addison, TX 75001
Time: 5 – 7:30pm

More information – and RSVP – http://www.geekmeet.com/our-cities/dallas-tx/

Penny Flow

Sean Robinson — Mon, 27 Jul 2015 17:51:10 +0000

Summary:

This game is based on The Penny Game. I’ve seen it in various incarnations, but this is based on the original concept. Instead of simply showing how batch size affects throughput, this game has been heavily modified to give several additional lessons. Attendees can expect to learn about Agile’s roots in Lean manufacturing, batch size theory, single piece flow, being adaptive to change, quick feedback and communication.

Each round after the first is essentially optional, you can choose exactly which lessons you wish to deliver. This may be all of them for more experienced teams, or fewer for those new to Agile.

Timing: 20 – 60 minutes depending on team size and number of rounds.

Materials:

20 x pennies
10 x larger denomination coins
Whiteboard / Blackboard / Flipchart
1 x stopwatch per team
Post-Its
Pens for Post-Its and board

Instructions:

This game will be run over several rounds, with each round introducing a new concept.

Setup:

Split your group into equal teams of at least 4, ideally not more than 6.
Choose one person from each team to be the timer.
If there are people left after this split, they can take charge of recording the results.
Each team should form a line, sitting down along the edge of some work surface, like a table length.
Ensure the timer for each team has a stopwatch.
Give each team an equal amount of pennies (around 8 – 15 is good).
You should now have equal teams with an equal set of coins, with everybody in the group having something to do.
Draw a large grid that will hold the scores for the completed rounds. Something like:

Round 1 – Batch Size:

Explain to the group that they each form a different team. Each team will complete the same work, which in this case is the flipping of coins. Each team member will need to complete the work in batches, before passing the batch to the next person. People are only allowed to use 1 hand, and the batch must be stacked in a tower before they can pass it to the next person.

Give each person a job title to model a real project. Commonly, this would be some subset of ‘Analyst’, ‘Designer’, ‘Programmer’, ‘Tester’ and perhaps something like ‘Acceptance’ if needed.

Tell the teams that you are the client, and that when the batch reaches you, they have delivered that value. Tell each timer that they must record the time it took for the first and last batches to be processed.

Finally, tell each team that they will be working with a different batch size. For 2 teams, use a full batch (the amount of pennies each team has) and 1 for the sizes. This will result in 1 team processing pennies individually before passing them, and another processing the whole batch at each station. With more teams, use intermediate numbers; so for 3 you would use 1, 5 and 10 perhaps.

Get each team to stack their coins in the required batch sizes. Teams working on a single coin can simply use a heap.
Start the teams working with a countdown.
Ensure players only use 1 hand and that the work is completed according to their batch size.
Ensure the time taken for the first and last coins for each team is recorded.
Stop timers when all work is completed.
Record scores in the appropriate sections of your grid.
Asks teams to discuss what they noticed.

Learning:

The conversation will often be limited with more experienced teams here, so it’s unwise to linger on lessons that are already known.
People should note that smaller batch sizes allowed other people to start working earlier.
Indicate that even if the final times were very close for both teams, the teams with smaller batches were delivering value almost immediately. Reference the Agile Manifesto with regard to early and continuous value.
The team working with a single batch size have been using single piece flow, first pioneered in the Toyota Production System. It is largely this process that helped fuel the Lean movement, later translated to software by Tom and Mary Poppendieck

Round 2 – Reactive to Change:

Tell everyone that you will be doing the same game, but with some additional coins. The timers will complete the same role as they previously did. All other aspects of the game will be the same.

Evenly distribute the other coins through the batched stacks of the teams.
Start the teams working with a countdown.
Around halfway through, announce that you have changed your mind and now only want the pennies.
Allow the game to finish and record the scores.
Ask the teams to discuss how the exercise went.

Learning:

Teams should see that with large batch sizes, there was a lot more wasted effort that went into processing and stacking unneeded coins.
Teams should see that larger batch sizes made it more difficult to separate the required from the extraneous work.
It should be noted that smaller batch teams were able to ignore the other coins once the change came in, reducing the wasted effort.

Round 3 – Quick Feedback:

The teams will now continue to use all of the coins, but change requests will no longer play a part.

Give each ‘Tester’ (Or simply choose one of the latter work centres in the chain) in your team a note that says the following: “We need all coins to be face down, reject entire batch back to Developer. You can say why.”. It is vital that this secret message is not shared with other teams or anyone else on their team. The aim is for the ‘Tester’ of each team to reject the first faulty batch, have it ‘reworked’, and then successfully complete the remaining batches.
Allow the game to finish as normal.
Ask the teams what they noticed.

Learning:

Teams should note that with larger batch sizes, the amount of work wasted was much higher.
Note that smaller batches allowed for significantly quicker feedback to the team, reducing waste.
Watch for teams repeatedly failing batches because the message wasn’t passed all the way back.

Round 4 – Bottlenecks:

This time we will model bottlenecks, and show the difference between local and systemic optimisation. Ask each team to identify their primary bottleneck. They should identify the first work centre as it is this person who delays the next from starting. You may see people identifying themselves because they are slow, steer the conversation towards a more general view.

Next, ask the team how they would optimise that bottleneck. You will generally see people saying that they would use more people. Use this and say you are going to simulate that by allowing that person to use two hands for the next round.

Tell the first person in each chain that they can now use 2 hands to process their batches. Each batch passed to the next person MUST be stacked on top of the coins that person is waiting to process.
Start the countdown to begin the game.
Allow the game to complete and record the scores.
Ask the teams what they noticed.

Learning:

The times should be slightly quicker here.
You are looking for the teams to mention that work started to build up further along the line as the rest of the team struggled to keep up. they should identify that resolving their primary bottleneck has given way to another.
Note that the work being built up before bottlenecks represents inventory. Show that this is expensive to store for companies and often increases overall time due to the extra work required in maintaining it (The stacking). This corresponds to the cost in manufacturing of storing large volumes of parts in warehouses. By eliminating the need for storage using ‘Just In Time’, companies reduced the cost of maintaining and transporting that stock. In software, this represents stories being stuck waiting for a person to complete the next step in the chain. This increases the cycle time of that story, delaying value.
Ask what would happen if you continued to optimise your first person. You would be unlikely to see a decrease in overall time because you were optimising something other than your bottleneck, this is the difference between local and systemic optimisation.

Round 5 – Optional:

You may additionally run the game with a further optimisation on the first player here, just to highlight the point of local vs. systemic optimisation.

Alternatively you could choose to allow all teams to optimise their bottlenecks by using 2 hands for every work centre. This would allow the teams to finish with their best output.

Concluding Notes:

For me, the benefit of this framework is that there are so many lessons to take from it. Different people will see different things, don’t be afraid to run your own experiments in additional rounds; even asking your teams if there is something that they would like to model.

Thanks:

Thanks to David Grant, Matt Pearce, Matt Grover, Steffan Liassides and the South Wales Agile Group for their assistance in refining this game.

Originally posted at: SeanTRobinson

Successful remote teams

Jane Prusakova — Thu, 23 Jul 2015 13:31:00 +0000

In this day and age of total technological connectedness working from home seems like a no-brainer. There is email that we check every passing second, the smartphone that can reach us anywhere anytime, and increasingly sophisticated tools that allow sharing any kind of elegantly structured and totally chaotic data across every imaginable divide.

Yet, telecommuting remains rare, and remote projects remain hard. Outsourcing, in its more typical implementations, fails spectacularly and often. Organizations’ worst performers are often found among those “working from home”. (Best performers work from home, too, but that’s a different blog post.)

Overall, distributed groups face higher challenges and more risks on the way to becoming strong, coherent teams. Remote contributors must strive harder to successfully work together with others, compared to the regular folks who show up to the office every day.

For a team to be successful, members must share a vision, a flow, sense of connectedness that allows to think and make decisions together while maintaining unique perspectives.People on successful, productive teams interact many times a day to maintain working relationships. These interactions can be small or profound, like a quick ‘hello’ in a hallway or a heated discussion over lunch. More importantly, such exchanges are typically informal, unscheduled, and “just happen” – and they are absolutely essential to keeping the team in great shape.

Successful distributed teams have the technological means to have these interactions, too – but the opportunities do not ‘present themselves’. When other team members are not within eyesight, it takes conscious, deliberate effort to think pick up the phone, start up an IM conversation, or send an email. It is even harder to regularly take the time to share a joke, a story, something that’s not immediately essential for the work at hand, but serves a more long-term purpose of maintaining team spirit.

People who work remotely regularly and with great success, have made these kinds of intentional “extra” interactions part of their regular routine. The same way mature teams, organizations and their members produce high-quality results, mature distributed teams, organizations and their members make sure to stay connected and engage in lots of team interactions.

The maturity and effort required for a productive, successful remote working relationship may or may not be visible to a typical regular office worker Joe, who is having grand visions of working from home in his or hers pajamas.

New Blog

Todd Meinershagen — Sat, 18 Jul 2015 16:33:00 +0000

For those of you that have been following this blog for a while, I wanted you to know that I have created a new blog that I will be posting to more frequently. You can find it here.

Hope you enjoy!

Agile Scrum framework at glance

Jesus Mendez — Tue, 14 Jul 2015 17:59:49 +0000

Purpose

The goal of the game is to start the conversation within the team about their development process, in this case, by using the Agile-Scrum framework. By asking open ended questions, the facilitator would help the team discover areas of improvement identified by the team, help with clarifying some concepts and show the team how easy it’s to inspect and adapt their own development process.

When to use it

This game could be used with new teams (everybody is new), when a new member is joining the scrum team or even when the Scrum Master/Agile Coach/Facilitator is the one joining the team. The main focus of the game is to get alignement about the Scrum framework, which could be used to guide the Scrum Master/Agile Coach/Facilitator with:

what needs to be improved and in which order (prioroty)
what’s unclear, unknown about the scrum framework. (What does requires reinforcement?)
what’s working and what’s not.

All that above, based on the team’s perspective.

Prerequisites

1) Agile-Scrum At Glance – Baseline

2) A facilitator

3) A board, some markers, some post-its and good attitude.

4) How many participants: minimun one, maximum to try out.

Timing

Preparation: 5 minutes to print out the required material
Duration: Between 50 minutes and 60 minutes, depending on how engaged the team is when discussing about what to improve

Instructions

Explore & Identify (5 minutes)

Distribute ”Agile – Scrum framework at glance baseline image” printed to each team member present in the room.
Tell the team to take a look to the “Agile – Scrum framework at glance baseline image” and ask them to write down one issue per post-it, about those areas in the chart that: (1)Require some kind of improvement (2) Are not clear/unknown
Note: it’s up to the facilitator to limitated the amount of reported issues, so then you can reach the time box that works better for you.
Set a timebox between 3 to 5 minutes, and then let the team alone writting down the issues found.
Once the timebox has gone, ask the team if anybody needs more time. If the answer is no, then move on to the next step.

Discuss (30 minutes)

Open the floor to discussion by asking for volunteers to expose identified issues.
At this point of the game, it’s suggested to ask open ended questions in order to clarify each identified issue.
i.e: What is important about the issue that you are presenting us?
i.e: What have you considered when raising the issue?
Once everybody has presented their own issue, it’s time to move on to the next step.

Group and decide (15 to 20 minutes)

Now that everything is discussed, ask for a volunteer to help the team with grouping all the post-its, by using the areas available in the “Agile – Scrum framework at glance baseline image”
Give the team some dots stickers to vote (usually I give them to vote = amount of members in the room – 1)
Once everybody has dot voted, ask them to organize the identified issues in order, based on how many dot votes has got.
Now aske the team to identify one action that could help the team with improving the identified issue.
NOTE: If something is unclear/unknown is up to you to decide when to explained. I usually do it, once the question is raised.

Expected outcomes

Common and shared understanding about where the team is regarding the Scrum framework
What’s important for the team, about the development process.
The team got empowered to adapt its own development process to its own needs.
A high level actionable improvement plan has been created by the team.
The first seed for a self-organized team has been deployed.

Thank you for reading.

All the best,

Jesús E. Méndez A.

www.jesusmendez.ca

Scrum in TV shows and in real life

Jane Prusakova — Tue, 23 Jun 2015 16:31:00 +0000

In an old episode of HBO “Silicon Valley” show, a soft-spoken MBA-bearing non-technical dude introduces Scrum to the hard-charging engineering team by presenting them with a Scrum board. The purpose of the system is declared to be “visibility into who is working on what”. As it becomes clear in the next 30 seconds, the actual value the team gets out of using the Scrum board (and, by extension, Scrum) appears to be the competition between the engineers who appear to work harder and faster on their separate stories to one-up each other.

So what is Scrum, and what does it do?

Scrum.org offers this definition: “Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs.” If that’s too complicated, here’s another attempt at an explanation: “Scrum itself is a simple framework for effective team collaboration on complex software projects.”

While this does not explain what Scrum is (one should take multi-day training courses to fully groke that), it starts to emerge that Scrum is about:

teams
complex projects
visibility into the work of and collaboration between individual contributors

First two items describe common reality, while the last one is often a hard-to-reach state.

Visibility and collaboration are a worthy goal for many organizations. Teams produce better value if all participants were fully aware of the overall vision and what other people are working on.

Collaboration and friendly competition are known to improve productivity and quality of the work. Installing and maintaining a Scrum board is a lot less work than adopting proper Scrum. Yet, it is a tiny investment with outsized return.

LinkedIn Talent Article – 5 things recruiters do that drive candidates crazy

Brandon — Tue, 02 Jun 2015 14:51:37 +0000

Saw this posting today from the LinkedIn Talent Blog, Author Paul Petrone. I think it rings true for a lot of people. From the recruiter standpoint, unfortunately we have some trouble getting information from clients in a timely manner or they will just say “we pass” on a candidate and will not give specifics on why. These things can certainly make a job search frustrating for a job seeker.

http://talent.linkedin.com/blog/index.php/author/paul-petrone

As a recruiter, we assume you don’t want to annoy candidates. Even looking at it in the most selfish way possible, it hurts your ability to close candidates and ruins your company’s reputation, which is never good for the bottom line.

So, to help you understand what irritates candidates most, we surveyed more than 20,000 professionals and asked them a pretty simple question: “What one thing frustrates you most about the recruiting process?”

While there was a wide-array of responses, five themes emerged. Without further ado, here are the five things recruiters do that drive candidates crazy and solutions for you:

1. They don’t keep candidates up-to-date

This is one of the most common responses we saw. People who didn’t get a job were upset when recruiters didn’t tell them. And, candidates who were still in the process complained that they only hear from a recruiter when it’s convenient for the recruiter.

Sample responses:

“Lack of communication. I’m left to guess that they’ve gone with another candidate because my phone stops ringing and my emails go unanswered.”

“Poor communication from the recruiter. They should respond back in a timely matter. They are the ones who made contact.”

“Recruiters can be very selfish with communication.”

Solution:

Keep your candidates warm by contacting them at least once-a-week, even if there is no new news to report. And let your candidates know if they don’t get the job, particularly if they interviewed with you.

2. The hiring process is sloooooooow

Another very popular one. A lot of people complained the hiring process was just too long and burdensome.

Sample responses:

“The process takes so long! Speeding up the application process would make me a lot happier.”

“It takes too long for interviewers to get back with recruiters and too long for recruiters to set up interviews. There appears to be no sense of urgency.”

“Length of the process.”

Solution:

Obviously, shorten the process when possible. But, if you feel like you can’t shorten it without compromising quality, keep candidates engaged by consistently communicating with them.

3. They don’t give straight answers

Quite a few people complained that recruiters didn’t give them straight answers about the position or embellished. Some even said they were outright lied to.

Sample responses:

“Too much mystery. More upfront information could save both parties a lot of time.”

“Selling the company for something it isn’t.”

“Recruiters tend to oversell the company. It’s tough to get an accurate idea of the good and the bad.”

Solution:

Lying or exaggerating about a position is never a good idea and will almost certainly have a negative outcome. Think about it – if you hire someone under false pretenses, how long do you really think they’ll stay? Obviously, the solution here is just to be as honest and straightforward as possible. That’s the only way to hire the best fit for the role and keep everyone happy.

4. They reach out despite knowing nothing about the person

This was another one of the most common complaints cited by professionals.

Sample responses:

“Recruiters who don’t bother to read my resume before contacting me.”

“I find that recruiters just troll LinkedIn for candidates and don’t actually look at my profile.”

“Recruiters having done minimal research or just cold calling without knowing my specific skills and contributions.”

Solution:

Not only is this annoying for candidates, it’s ineffective for recruiters. Targeting the people who are most likely to accept the job and then researching them before you reach out is the most effective way to recruit passive candidates.

5. They don’t know the job. At all.

This was a particularly common complaint among people who work in the technical fields.

Sample responses:

“Recruiters usually have little knowledge about what the actual job entails besides what’s written on the job description. It doesn’t give them much credibility.”

“Most recruiters don’t speak with knowledge of the industry or job they are hiring for.”

Solution:

You don’t necessarily need to be an expert in the field you are recruiting in, but you should at least know it enough to have a conversation about it. So, be sure to have at least a cursory knowledge of the position and what it entails before reaching out to candidates.

To learn more about what talent is experiencing and what they like (or don’t like) during the job-seeking process, download our free 2015 Talent Trends report.

Weekend Escape an agile backlog management game

Andrew Rusling — Tue, 26 May 2015 09:58:53 +0000

Timing:

20 minutes to prepare plus 30 minutes for Standard version, or 75 to 90 minutes for Extended Version

Overview:

Small teams collaborate to order a backlog with a specific business goal in mind. Once the team has produced their backlog, they review the output of another team and discuss the differences. Everyone participates and discussion plays a key part in the game. Participant’s eyes are often opened to the complexity of backlog prioritisation. The game has been designed for all staff, not just Product Owners. The Extended Version of the game ramps up the challenge. It is aimed at Product Owners, yet suitable for anyone with a little more time to spare

Learning Points:

Experience the challenges of prioritising and ordering a backlog.
Understand how an agile team can help their Product Owner by making the backlog items easier to compare.
The Extended Version also adds the experience of how business goals impact your approach to prioritisation.

Example of resulting backlog:

Link to Game: Instructions (PDF)

Agile Clock

Illya PAVLICHENKO — Mon, 18 May 2015 13:34:04 +0000

Do you want to pass a small test? It is very simple – please reproduce in the exact sequence literally four values of Agile Manifesto.

Well, how did it go? If you succeeded, then you get my congratulations.

3 years ago I failed the test, though I knew the Scrum Guide almost literally and was extremely proud of this fact.

Now I often have to explain this “cultural thing” (Agile Manifesto) to managers and company owners. After all, most of the organizations want to implement Scrum now. But they always learn about the “culture” from me first and only then get the desired framework itself. To put culture ahead is quite natural approach for an Agile Coach.

Talking about Values. Values are often interpreted differently. For example, ask your friends what they mean by “Trust”, and you will get a lot of different answers. Which one is true? Each of them. Values are quite abstract, nevertheless they are expressed in a certain human behavior. We always look at the world through our own glasses. Therefore, the meaning of values should be clarified first. Then we can agree on certain observable and measurable patterns of behavior that support those values.

A proper understanding of Agile Manifesto is VERY important for the subsequent introduction of Scrum. I used to go beyond the four values and always suggest to clarify the twelve principles. They are less abstract and can be easily understood. I often use the game which I call ”The Agile Clock.”

Agile clock. The game is based on an exercise Pocket-sized Principles. For the game we need:

About 30 minutes of time.
Bikablo Icons or stickers 76×76 mm.
Printed 12 principles of Agile Manifesto.
Flip-chart paper.
Paper tape.
Scissors.
Stickers.
Timer.

Divide participants into groups of no more than 5 people. This is the most comfortable group size for any discussing or problem-solving. Every team is given a copy of 12 principles of Agile Manifesto.

The challenge – within 20 minutes each team needs to express the essence of each principle in three words or less. Words should be written on stickers and hung within the circle on a flip chart. Thus, we create the clock. Each number on the clock corresponds to a specific principle of Agile Manifesto. Also, I ask to choose the most appropriate icon from the Bikablo Icons set for each principle and pin it to the flip-chart too. If the set is not available, then I ask to visualize the principle by hand.

Very soon each team has a smart Agile Clock. Additionally I give 3-5 minutes to wander around the room and examine the clocks made by other groups. Then it makes sense to go through the principles and briefly discuss them.

Visualization and metaphors always provide excellent results in teaching for me. People quickly come to a common understanding Agile Manifesto principles and remember them for a long time.

And finally, my advice to you – from time to time re-read the values and principles of the Agile Manifesto. They inspire and help to focus on the most essential points.

Texas – Hot Job Market

Brandon — Tue, 12 May 2015 16:48:55 +0000

Recent Dallas Morning News article stated that Texas is one of the hottest job markets in the US.

Texas and Florida top the list, according to a new report from ZipRecruiter. (See full list below.)

Why? The recovery of Sunbelt real estate markets, continued in-migration from other parts of the country and lower business costs translate to more demand for jobs.

Overall, the southern part of the United States has been the top performing region for job creation over the last 20 years. Last year, 23 of the top 50 job markets were in the South, which posted an average jobless rate of 5.5 percent, according to ZipRecruiter, an online recruiting site for small businesses.

Texas ranked No. 2 (+407,400 new jobs) behind California (+471,200 new jobs) in 2014.

ZipRecruiter also analyzed hiring demand trends to determine which industries saw the greatest growth so far this year in Sunbelt metro areas. The biggest job demand has been in the trucking and transportation industry, followed by information technology jobs and biological research.

TOP 20 METROS FOR JOBS
1	Tampa-St. Petersburg, Fla.
2	Dallas-Fort Worth
3	Houston
4	Richmond, Va.
5	Jacksonville, Fla.
6	Memphis, Tenn.
7	Roanoke, Va.
8	Greenville, S.C.
9	Huntsville, Ala.
10	Orlando, Fla.
11	Cape Coral-Fort Myers, Fla.
12	Durham, N.C.
13	Greensboro, N.C.
14	Winchester, Va.
15	Spartanburg, S.C.
16	El Paso
17	Danville, Va.
18	Lubbock
19	Mobile, Ala.
20	Myrtle Beach, S.C.

ODE - Outcome Driven Enterprise - The Mindmap

CharlesGary — Fri, 10 Apr 2015 12:20:00 +0000

How to work with a Recruiter

Brandon — Thu, 12 Mar 2015 16:17:31 +0000

In the IT Field, job seekers are typically in one of two categories, they either work with recruiters all the time as contractors, corp to corp, or W2 hourly or they change jobs every few years. Those that work as contractors, typically have a specific skill set and niche that there might be a few recruiters they work with in that skill set -(Business Intelligence & ERP both come to mind). Others may work in a general area (Systems, Networking, Java, .NET, Databases, Open Source) which might require working with multiple recruiters to find a position and aren’t familiar with how things work.

In general, there are some tips you may want to use when looking for a position and working with recruiters.

Make a list and keep track of the positions you have applied to. There are times when companies work with several different recruiting vendors for the same position. This causes an overlap in recruiters going after the same talent. As a result, candidates may be contacted by 2-3 recruiters for the same position. Make sure that your resume isn’t sent by more than one agency recruiter, this will hurt your chances and sometimes eliminate you from being considered.Find out who is submitting you and keep track when it was sent.
If you see a position you are interested in, find out if any of your contacts work there or if any of the recruiters you are working with has them as a client. Sometimes going through a recruiter, your chances are better since they have direct contact with the hiring manager. If you apply directly to the role, the recruiter will not be able to assist you since their fee is tied to presenting the candidate.
Keep your recruiters informed of what is going on with your other interviews. It helps if you are honest with them about your other activity and that way companies can move on to other candidates. If you are certain about an offer pending in the next day or two, it doesn’t make much sense to take a phone screen that day.
Be clear on what you are looking for in a new position when you are talking to a recruiter so they are able to match you with the right company and role. (Location, Salary, Benefits, Duties/Responsibilities). When it comes to salary, be as specific as possible and let them know the range you are looking for and minimum/bottom that you would consider.

Good luck in your search!!

A story of one code review

Jane Prusakova — Thu, 19 Feb 2015 11:27:00 +0000

As told by a developer:

A. and D. told me that the changes that were done to method “E” on class “C” are not needed, and also those two test cases for these changes were not needed. So A. and I removed those. I promoted these changes to my stream.

I don’t really understand why.

Also A. said that the test “T” should make sure we are asserting that those values are really still there. I thought it did do that, but I guess not.

Also D. suggested an improvement to the code that I don’t fully understand: In class “U” method “D” we can pass the “c” into the “T” method on line 35 and then we don’t need to pass it in on line 39. I didn’t catch exactly what he was saying to do.
I may be missing some other things too.

I hope the code was improved as a result of the changes made based on this code review. But even so, this is not the best way to run code reviews.

Code review is there to get all the team members on the same page in regards to writing good code, catch hard-to-detect issues, and learn from each other. The discussion that happens in code review is an invaluable tool in building a strong technical community, and ensuring the technical quality immediately and over the medium- and longer-term. It is important that all participants gain an understanding of what changes would make better code and why, in addition to simply following typing instructions.

Here's a slide deck "Effective Code Review" for a discussion about code review practices , that focus on learning, creating a community with a common vision, and building social capital.

Are we having fun yet?

Jane Prusakova — Sun, 08 Feb 2015 00:11:00 +0000

Legoland theme-park has very few Lego creatures. A staff member explained:

- It is a lot of work building them out of small bricks.

That just sounds backwards. Building with Legos is fun, not work. How can that be?

For the folks working at the Legoland building from Legos is hard work. The resort operates by strict, unbending rules. Cheerful staff, while smiling and genuinely trying to be helpful, is going by a well-memorized script. Thinking on the job is discouraged, and absolutely no initiative or having fun is permitted. These guys look and act like well-behaved robots, which they are payed to be during the work hours. Robots do not have fun, no matter the activity.

Most of us are not paid to build Legos, but a lot of our jobs can be no less fun and creative than putting little colorful bricks together. It is important to not let rules, scripts, and check-your-humanity-at-the-door culture ruin that fun.

Empowering Agile teams: culture clash. Part II

Jane Prusakova — Thu, 29 Jan 2015 12:11:00 +0000

This is a follow up to the earlier article on this blog "Empowering Agile teams: culture clash".

Agile frameworks empathize empowered teams, flat structures, and meritocracy. Agile transformation is about re-defining who holds authority and responsibility.

Agile approach both allows and requires all participants to care. This is the other side of the struggle. While it is hard for command-and-control management to step away and let the team self-manage, it is even harder for the team members to suddenly start to care.

Power concentrated on the top of the org chart leads to classical principal-agent problem. In many a traditional organization team members have no reason to care about technical quality, steady pace of delivery, or building the product that customers actually want. Management makes decisions about what gets done and how results are accessed, and carries responsibility to the customer. Team members are expected to show up and do what they are told.

Self-managed teams, the corner stone of the Agile organization, have the information, the skills and the power to deliver what the customer wants. To become self-managed and claim that power, the teams also needs a will, and perhaps some incentives, to care about the organizations’ success. Agile transformation is about reminding people of their power, and waking up that will to care and be in control.

Good Agile teams break the rules

Jane Prusakova — Thu, 18 Dec 2014 00:07:00 +0000

Agile frameworks are sets of rules. To become Agile, an organization or a team learns these rules, tries to understand what the rules mean, and executes according to the rules. Not necessarily in that particular order.

Good teams learn rules quickly and follow the rules well. Or do they?

Agile philosophy is all about learning, gathering information and feedback, making small changes, and gathering feedback again. As teams mature and understand the philosophy of being Agile, a rule may get re-assessed, adjusted, and sometimes even completely disregarded. The team will consider the outcome, and either go back to the previous version of the rule, stick with the updated rule, or make another change based on new learnings.

Consider this example, discussed by Mike Cohn: standard Agile rule recommends that the team works on backlog items in the order set by Product Owner. But depending on the technical details of the project, the team may be able to maximize delivered value if it is allowed to do minor adjustments to the order of stories.

Another standard Agile rule that is often broken is to use collocated teams only. This rule is often not followed due to business constraints, and in those cases breaking this particular rule can and often does lead to serious problems. However, more mature Agile teams that choose to let some members work remotely part of the time, can stay productive and perform on par with completely collocated teams. Being able to occasionally work from home helps people concentrate, allows to save time on the commute, and overall improves enjoyment and morale of the team, which promotes better productivity.

Rules of the Agile frameworks are designed to help teams create a situation that encourages learning, taking responsibility, and enjoy their work. Teams that have developed a deep understanding of the reasons behind the Agile rules, should be allowed and encouraged to modify the rules to fit the details of their physical environment, particular complexities of the project, and organizational specifics. A mature self-managed Agile team can be trusted to develop their own rules for best performance.

Myths and half-truths about estimates

Jane Prusakova — Thu, 11 Dec 2014 18:33:00 +0000

Estimating is in our DNA. It is about the future, the knowledge, the power – all the things that make us feel in control. Estimates are required, and are the most straightforward (or even the only) way to gain trust, and budget, to go forward.

Yet… it is an open secret that estimates are flawed. Things do not go as planned. Resources become unavailable, assumptions turn out to be incorrect, changes trickle down in a never-ending stream, and communication becomes strained.

While having flawed estimates may be preferable in some situations to having none, commitment to wrong numbers can wreck havoc on any project. If you are going to estimate, steer clear of these mistakes people frequently make, even if they have plenty of experience with estimating.

Myth: If your estimates are a range of dates, you are doing a good job managing expectations.

Only the earlier, lower, more magical numbers will be remembered. And those will be accepted as firm commitments.
The lower bound is usually set at "the earliest date the project can possibly be completed". In other words, there is absolutely no way the work can be completed any earlier, even by a day. What are the chances of hitting that exact date? Practice shows - close to nil.

Half-truth: You can control the quality of your estimate by putting more work into producing this estimate.

By spending some time learning about the project, researching resources available, considering major and minor risks, one can produce a somewhat better estimate.
The above activities are only going to take the quality of the estimate so far. Past a certain point, no matter how much effort goes into estimating a project, the quality of the estimate is not going to improve. Then the best bet is to simply start working on the project.

Myth: People can learn to estimate better, as they gain experience.

It is possible to get better at estimating – if one keeps estimating the same task, which becomes known and familiar with experience. This is hardly ever the case in software development. Every project is different, most teams are brand new, and technology is moving along fast enough.

Do not expect to produce a better estimate for your next project than you did for your last one.
By the same token, do not expect a worse estimate. The quality of the estimate is going to be low, and it is going to be random.

Half-truth: it is possible to control the schedule by giving up quality.

Only for short-term, throw-away temporary projects.
For most projects, aiming for lower quality has a negative effect on the schedule.

The human side of enterprise

Jane Prusakova — Wed, 12 Nov 2014 21:13:00 +0000

Once upon a conference, I asked a small technology business owner about the interactions his 12-person team had, and he was sincerely surprised by the question. “Why would they need to talk? I tell them what to do, and then they code, each in their cubicle.” – was his response.

We like to think about work strictly as job function-dictated activities. Gathering requirements, evaluating options, making product decisions. Meeting to discuss who does what, how hand-offs happen, what are the acceptance criteria. Org chart-based relations that dictate who is in charge, who reports to whom, and who will get the credit or blame. The result of these interactions is work product, the how-to of getting to a solution.

Yet, there is more to work than “just work”. It is also the true, human relationships we develop with people we spend a lot of time with most days of the week. A quick exchange by the water cooler about a concert, a site of a geeky new mouse pad on someone’s desk, kids’ pictures on the screen. A small group is discussing the latest smartphone while getting coffee; when waiting for a meeting to start someone mentions that she is looking for a rock-climbing gym; and somebody else is asking for advice on the user groups during lunch. The result of these conversations are not necessarily a work product (although it could be directly useful for work, too), but the building of a team of friends.

A team comes together through learning small, personal, often seemingly insignificant details about each other, discussing experiences, finding shared interests. Working with friends matters. It is a lot easier to be open-minded and welcoming to a friend’s ideas, than to someone’s who is a stranger. Friends deal with disagreements by working together, while strangers get upset and push each other away. Knowing and liking people one works with makes everyone happier and more productive.

When the opportunities for social interactions within a team are limited, work suffers. Teams of strangers are less interested in working together cooperatively, sharing information, establishing and striving toward a common goal. There is more shirking, less innovation and leadership. And less success.

Simple solutions to complex problems

Jane Prusakova — Thu, 06 Nov 2014 19:41:00 +0000

Complexity and simplicity are often, and intuitively,
regarded as two extremes of the same continuum,
or spectrum. Yet, this may be a simplistic view, indeed.

Complexity of a solution reflects many things: complexity of the problem, of the problem domain, the level of understanding of the above by the people creating the solution, and the complexity of the organization and communication of the people in charge of building the solution. Finally, complexity of the solution will reflect the incentives people were facing: was it in their interest to create a complex solution? Or to make the solution as simple as possible?

Integer calculator is inherently less complex than, say, mapping software, but implementation of the algebra functions can be ridiculously complicated. Or fairly simple, depending on the attitudes of individual architects and implementers, and their organization. Business rules expressed as decision trees are relatively simple, yet there are plenty of solutions in that space that are mind-bogglingly complicated.

Agile approach results, among many other things, in reduced complexity in the delivered product. Cross-functional self-managed teams, while not easy to build, are a lot less complex than matrix organizations of the traditional firms. Communication patterns are simpler and more straightforward. Preferring a team of generalists over narrowly specialized experts levels out the playing field, and encourages more level understanding of the problem domain within the team. The emphasis on speedy delivery of small slices of the solution leads to the team concentrating on the “lowest hanging fruit” at any point in project timeframe, ensuring that the team works on the best-understood pieces of the problem, while it expands its understanding.

Engineering practices that are often coupled with Agile also carry a significant focus on simplicity in design and implementation. Emerging design, developed with continued and immediate feedback from the implementation and user assessment, is simpler than the up-front design created early in the project, prior to having project work feedback loop established. Unit-level automated tests are simple to create and maintain, and having adequate test coverage and infrastructure reduces both probability and complexity of inevitable bugs.

Frequent collaboration with users and customers, required by most Agile frameworks, forces all parties involved in a project to develop a joint understanding that eventually becomes the basis of the solution. Joint understanding of a diverse group is always less complex and less nuanced than that of a single mind (participating in the group), or a similarly-minded group, thus leading to a simpler solution.

As the business of software development moves forward, it is taking on more complicated problems, and attempts to deliver increasingly complex solutions. Keep the complexity in check by simplifying communication paths, promoting learning and feedback, and striving for joint understanding among diverse groups.

Never talk to strangers

Jane Prusakova — Sun, 26 Oct 2014 21:49:00 +0000

People as species have evolved in social groups, cooperating and competing. Simply sharing a space helps to build trust, create a body of shared knowledge, establish social customs. Patriotism, love and pride for one’s land, interest in tails of the forefathers are all feelings that knit together a community of people that live and interact in close proximity.

But when it comes to interacting with people from far away, the situation is different. Historically, people living afar have been perceived as either villains or gods. People who are not participating in every day events in person, if they are not completely disregarded, appear weird, scary, and are ascribed bad thoughts and behaviors. Tribes everywhere are known to have fought long-lasting wars with neighbors living just far enough to not be part of the community.

The entire human history has prepared us to like and trust those close to us, and expect bad things from people who we cannot see, hear, touch and smell. We may not be consciously aware of this bias, but it is impossible not to notice its consequences. Long-distance relationships have a dramatically lower rate of survival, compared with relationships where partners see each other regularly. Most business activity still happens locally, within a single geographic area. Despite the televised debates and online advertising, politicians still fight and win elections by talking to voters on the campaign trail, and building organizations of supporters to do that on candidates’ behalf.

When an organization is working with a remote team, the people on that team are outsiders, not part of the tribe. Remote team members, unable to participate in daily face to face interactions, are subject to all the suspicions and biases outsiders have suffered throughout the human history. To create trust and build good working relationships all sides must work against their natural instincts of distrust toward outsiders.

There are many things that could help make the remote team a part of the inner circle. It could be as simple as giving a voice on the phone a benefit of the doubt – and a chance to explain in greater details how they came up with the ideas being presented. Or as complicated as organizing regular trips to a common location, to let people spend time together, working face to face. Whichever way is chosen, it is still hard work, requiring intelligence, an open mind, and willingness to learn.

Happy Hour – Geekmeet – October 22nd

Brandon — Tue, 21 Oct 2014 18:29:15 +0000

Happy Hour – The Lion & Crown — RSVP! Also, look out for Happy Hours in Nov & Dec – coming soon.

GeekMeet Dallas

Wednesday, October 22, 2014
5:30 PM – 8PM

Lion and Crown
5001 Addison Cir
Addison, TX

The "family" objection

Jane Prusakova — Mon, 20 Oct 2014 16:04:00 +0000

We recently held a panel titled “Software development is a team sport: Women In Technology” at Houston TechFest in Houston and Austin CodeCamp in Austin, Texas. The goal was to have a conversation about men and women working together in IT and software development industry. Research shows that we are more productive because of our differences, not in spite of our differences, when we manage to work together. We had great participation: men and women shared stories, concerns from their experience, concerns they have for their daughters, difficult situations and techniques that worked in different environments.

Each time, there surfaced an old-time objection to hiring women:

- Why hire a woman, who may get pregnant and go on leave for weeks, and then perhaps be somewhat distracted for a few more months, when one can perfectly well hire a man, who is not in any danger of ever bearing a child?

This entire line of reasoning strikes me as odd.

Fertility rate in the US is 1.9 children per woman, i.e. over a lifetime an average woman is expected to have 1.9 kids. Women with more education tend to have fewer children, so for women with a college degree the average is just 1.1 children.

A college graduate typically has a 45+ year career, male or female, first entering the workforce at age 22 and working at least until his or her late 60s. Today’s typical tenure in IT at a given position, job or company is 2-5 years.

So, a woman interviewing for a job today, has an approximately 2-in-45 chance to have a child while working at this job. If she already has a child, that chance falls to 2-in-450.

In order to get this interview, this woman has shown herself to be a stronger candidate than, typically, 2 to 100+ other people, who also applied for this position. She still has to beat 2+ other candidates, also invited to interview for this position. Overall, her chances of becoming the top candidate are between 1-in-4 and 1-in-100, which makes her (or anyone reaching that point) quite awesome!

Now, consider another angle. Productivity among mediocre, good and great developers varies by orders of magnitude. Hiring the best person for the team makes a significant difference in bottom-line productivity, quality, time-to-market and maintainability of the project. A woman who is x10 as productive as the next candidate, even if she takes 2-4 months (over her 2–5 year tenure in a particular job) to take care of her family, is still a net win for the team with a realized productivity gain of 90%+. And this is the worst-case scenario! In a typical case, your best candidate will deliver an even better value, regardless of her gender.

The argument about women's propensity to take time off to have children makes no sense in the context of hiring the best person for a software development job. Any organization's best bet is to identify and hire the best person they can get, and then make sure that person stays with them as long as possible. Regardless of their gender.

Discussion about good code at DallasTechFest 2014

Jane Prusakova — Sat, 11 Oct 2014 14:05:00 +0000

Many programmers are dedicated, or even obsessed, with writing “good” code.

Often we follow certain patterns and practices because we believe they are the best solution for the problem, or because the experts tell us so. There are many quasi-religious wars about proper ways to write code; those wars last years, inflame the most peaceful communities, and make many heads spin.

While it is easy to argue whether a particular piece of code is good, it is hard to come up with an overall idea of what makes code good. We had an interesting discussion about good code at Dallas TechFest, with a great crowd of fellow developers.

@jprusakova speaking on the aspects of good code. Totally full room! @dallastechfest #dtf2014 pic.twitter.com/6o0AyQ8YbA
— Ty Crockett (@TTCrockeTT) October 10, 2014

New Opening: Sept 14th – Windows Systems Engineer – DFW Airport area

Brandon — Mon, 15 Sep 2014 03:19:08 +0000

Here is a new role that we have available with a client in the DFW Airport area. If you are interested, email me at brandon@dallasetechrecruiter.com

They are looking for a Senior Level Windows Systems Engineer Immediate need, will move quickly. If anyone comes to mind, we offer $500 referral bonus.

Full-time, direct hire – DFW Airport area
Senior Level Windows Systems Engineer

Here is what they are looking for:

Bachelor’s Degree or equivalent experience
5+ years in Infrastructure experience
5+ years installing, maintaining, troubleshooting Win 2003 / Win 2008 in a large enterprise
Windows Server specifications – (Active Directory, DHCP, GPO, etc)
Experience with Linux/Unix
In depth knowledge of Virtualization – VMWare and/or Hyper-V
Scripting knowledge – Powershell or VBScript
Automation technologies and tools
Networking expertise
Fast paced environment, 24/7 with on call rotation
Great benefits and good working team

Windows, IT Staffing, Systems, Dallas, Linux, VmWare

Dallas TechFest 2014

tmgirvin — Thu, 04 Sep 2014 18:24:15 +0000

Dallas TechFest is back! It’s organized by my friend and colleague, Tim Rayburn. This year you can expect excellent content focused on Bleeding-Edge Development, Wicked UX and Next-Gen Mobile Technologies. (including iOS, Windows Phone, NodejS, ASP.NET vNext and Xamarin), plus interesting insights on UX and Mobility from Jared Spool, CEO & Founding Principal of UIE. The ticket price includes the full conference and lunch. Consider attending and please feel free to pass this information on to others you think might benefit from it

Dallas TechFest – Oct 10th @Gilleys in Downtown Dallas

Brandon — Thu, 04 Sep 2014 15:11:02 +0000

DALL☆S TECH FEST brings the best and brightest speakers from around the country to provide one day of incredible, densely packed content, focused on increasing your team’s ability to successfully deliver projects. This year we’re adding a strong focus on user experience (UX) and mobile development, ensuring you have the right skills at the right time. From iOS to Windows Phone,NodeJS to ASP.NET vNext, this is your time to learn.

Visual Studio 2013 Quality Tools

tmgirvin — Thu, 21 Aug 2014 15:43:26 +0000

I’ve delivered a talk a couple of times recently covering the Quality Tools in Visual Studio 2013 and Microsoft Test Manager. Specifically, this talk covers:

Unit testing
TDD
Automatic Test Runner
Manual Testing in MTM
Recorded Manual Tests
Converting Test Recordings in Coded UI Tests (CUIT)
Recording CUIT directly in VS
Build automation with Tests
CUIT Test Automation

I’m uploading my Visual Studio 2013 Quality Tools presentation here, even though it’s not that useful without the product demos to go with it. I guess it’s primarily reference materials for those who have actually seen the presentation. Maybe I’ll do screen-shots later and embed them to make it more stand-alone.

Stretch your mind

Jane Prusakova — Sun, 17 Aug 2014 22:17:00 +0000

“The more you know,
the more you realize you know nothing.”
– Socrates

There is a big push on young engineers (and colleges that educate them) to build up a wide variety of popular, currently in-demand skills. More popular technologies, common platforms, more courses and projects give students a better chance to hit every bullet point in job recs. It is favorably considered by recruiters and looks extremely attractive to hiring managers who think they are getting a well-rounded engineer at a recent-graduate salary. In addition, it sounds impressive in casual conversations with peers and professionals alike.

Unfortunately, breadth often comes at the expense of depth. Mastering depth of understanding fundamentals, theories and concepts that are the foundation of modern technologies takes time, effort and dedication to learning. It also takes a lot of effort to learn to work in technologies that give developer more direct access to underlying systems, and data structures. It takes passion and drive to gain an understanding of how to use any technology well, and to set high standards for one's work.

Those with deeper understanding, and the curiosity to gain that understanding, go on to become better software engineers and architects. While not immediately required by a job rec, knowledge of the underlying concepts is regularly needed to solve tough technical challenges in real life. Familiarity with more difficult concepts and technologies makes it easier to learn the popular and simpler ideas that change many times throughout one's career. It is well-established that ability to learn, to think critically and creatively is trained by pushing the mind out of its comfort zone, studying hard, understanding rather than memorizing.

Popular technologies and skills that are “hot” in the jobs market are designed to be easy to acquire, and to solve a narrow set of common business problems, with the trade off that these technologies may not be well-suited to a wider range of applications. These skills are easy to learn and apply. The difference comes in the speed of learning, the quality of outcomes, and the critical thinking that better engineers bring to the job, together with the technical skills. In a competitive marketplace, those who went through the trouble of gaining the deeper knowledge of computer science fundamentals, software construction, and code craftsmanship will fare better.

Improving Enterprises – AgileDotNext – Aug 22nd in Houston

Brandon — Tue, 12 Aug 2014 22:37:51 +0000

Two are better than one

Jane Prusakova — Sun, 10 Aug 2014 00:11:00 +0000

“If you can't explain it to a six year old,

you don't understand it yourself.”

― Albert Einstein

Pair programming is uncomfortable, exhausting, and un-ergonomic. With pairing it takes two or more people to do a job of one. It is time-consuming to organize, tiring to participate in, and painstakingly slow to observe. The benefits are non-obvious.

Code reviews are nerve-wrecking, aggravating, and painful. They take enormous amounts of time, bring out the worst attitudes, and spur religious wars on code minutiae. Results are often inconsistent, suggestions are petty, and resulting improvement is invisible.

Yet, there is plenty of evidence that teams that manage through the pain and find the time to pair, to review, to swarm, to mob-program, and to work together using any other technique, do significantly better. Pairing and code reviews contribute greatly to the value being delivered in higher product quality, shorter time to release, and in lower maintenance costs.

It comes down to a simple truth, noted a long time ago:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” - Brian W. Kernighan and P. J. Plauger

Left to our own devices, we want to be clever. But if we have to explain every turn of logic, every leap of faith, and every tiny assumption to another human, the desire for cleverness retires to the back of our minds, and leaves the center stage for the desire to be understood. This difference alone causes a big improvement in the work that we produce. Readable code has a much better chance of being good code, than code that’s hard to read.

It also means that the person reviewing the code, or being the non-writer in the pair does not have to be a developer, she could be anyone familiar with the product. Even if that person does not contribute directly to the code, their questions will influence the programmer to write better software.

In the case of two or more developers working together, in addition to producing better code, all involved will be intensely learning from each other. And that’s the best thing that could possibly happen to developers.

[It will also make them tired. I suggest getting a lot of colorful plastic balls, and investing in the fanciest espresso machine your office can afford.]

More Agile smells

Jane Prusakova — Tue, 29 Jul 2014 14:11:00 +0000

"Agile" means many things - there are Agile processes, Agile values, Agile ways of working together as a team. Becoming truly Agile requires a lot of education, willingness to keep an open mind, and lots of trust within the organization.

When things are less than perfect, as they usually are, many teams get to experience "an Agile smell". Agile smell, similarly to code smell, is not necessarily a problem by itself, but rather a likely indicator of a serious problem with the team’s implementation of Agile.

Learn to identify Agile smells, and the problems that may lead to them. Then get busy fixing the problems.

Smells "Our KPIs measure the wrong thing"

Team talks about velocity points, rather than discuss stories and value created
Members worry about being busy and putting in hours, rather than about producing valuable results
The team strives to meet arbitrary deadlines, rather than focus on delivering quality working software

It is tempting to measure the team's success by velocity points archived, hours worked, or hitting deadlines. But velocity points are imaginary and unequal units, that differ from team to team, and even for the same team over time. They are too easy to game. Same with deadlines - deadlines are derived from imperfect estimates, and hitting those deadlines causes loss of quality and team spirit. Hours worked is straight-forward to measure, but has little correlation with value delivered.

Smells "We are not using our tools well"

The information in the tool is treated as the source of higher truth, rather than a starting point for a conversation
Fill out the fields by the letter of the rules, rather than store useful information in an easy-to-understand format
Use the tool insofar as the process requires it, but are uncurious about better ways a tool can help us improve

Tools are there to serve the team. They help to compile information over time, store details, and offer a choice of presentation layouts. Tools are not there to drive the team's value, do the work of coordinating and facilitating communication, resolve issues. It is OK to tweak the rules imposed over a tool usage, if it helps the team to work smarter. It is not OK to be a servant to the tool, rather than its master.

Smells "We are not being awesome"

Compile excuses why we are not doing a good job, rather than look for a better way to work
Look for ways to make Agile process entertaining, rather than focus on the excitement of delivering great software
Build Chinese walls between specialties, Agile team members and their responsibilities, rather than work together

IT and software development is complex and complicated work. Every team that works hard and strives for success is going to make mistakes sometimes - and that's OK. In fact, it is good, because the only way to not make mistakes is to play it safe, aspire to little, and settle for less.

Problems do happen, and it is important to admit and examine what doesn't go well, take responsibility. So that the team can improve, do better in the future, and have fun while doing it.

This is a second post in the series on Agile smells. Read the first part here.

Empowering Agile teams: culture clash

Jane Prusakova — Wed, 23 Jul 2014 23:37:00 +0000

"The test of a first-rate intelligence is the ability

to hold two opposing ideas in mind at the same

time and still retain the ability to function."

- F. Scott Fitzgerald

Agile frameworks empathize empowered teams, flat structures, and meritocracy. Team members and those in supporting roles are expected to earn trust and respect, rather than get authority based on org chart.

Organizations in general do not work this way. A modern organization is all about hierarchy, where authority comes from one’s position and place on the chart. Responsibility and decisions each travel in exactly one direction in the hierarchy: decisions come down, responsibility goes up. This kind of structure is easy to manage from the top. But it does not lead to best decisions.

An Agile team is encouraged to take control of, and responsibility, their own work, but it comes in direct conflict with the not-so-Agile organizational structure. Entire corporate cultures are built around deferring to someone with a higher title. Those cultures do not disappear when an authority figure up the hierarchy decides that some projects should try Agile.

People on an Agile team are taught to care about producing value, make their own decisions, and take responsibility – but for employees with years of experience in traditional organizations it is not easy to accept this kind of message at face value. It is even harder if Agile has a narrow mandate, for example, when transformation is happening only in a small part of organization.

This cultural shift is the hardest and the most painful part of a large-company Agile transformation. It is also the most valuable change a business can make to improve its culture.

Calendar App – Mynd

Brandon — Wed, 23 Jul 2014 20:14:26 +0000

I have started to play with this iPhone Calendar app and really like it. You can add your LinkedIn Connections, add categories, and the daily display is a lot better than the standard iOS calendar. Give it a try!

Everybody wants a pony

Jane Prusakova — Thu, 17 Jul 2014 21:16:00 +0000

In a recent conversation, a colleague mentioned that a project his team worked on was considered a failure. That surprised me. I heard that this team delivered a high-quality product; the software quickly went into production, and has been delighting users for some time now.

Turns out, when the team first got started on a project, it came with a specification document and a deadline. As the work proceeded, the team was learning more about the project. A number of features were added based on conversations with stakeholders and organizational knowledge, other features described in the specification document were cut. Technical complexity was uncovered, and eventually conquered. The team iteratively delivered the system for stakeholder review, each time presenting more functionality, and at some point it was decided that the software is ready to go into production.

Well, as it happened, for this particular project the production release date was after the original deadline set on the project, back when the project consisted only of a specification document and that deadline. Therefore, the deadline was declared missed, and the project was declared a failure.

I find this mind-boggling. Before anything was known about a project except that there is software to be built, there was this random date. Now, that the world moved forward, the project came into existence as a working, helpful system that delights users and produces real, tangible value for the organization. Yet, somehow, that original date is still the deciding factor whether the project succeeded. Conforming to this picked-before-we-knew-anything-important date is more important than whether the project was delivered at all, whether it useful, or valuable, or makes users happy and productive.

It's understandable that people and businesses want a pony – projects that are predictable enough to be able to forecast completion date, scope, and user satisfaction ahead of time. In practice, most of software development work happens on complex projects, with a lot of unknowns, where information is uncovered gradually as more work is done. There is a very little chance that any given project is a pony. More likely it is a zebra, with a variety of stripes, and lots of unpredictability.

Estimates in the real world

Jane Prusakova — Sat, 05 Jul 2014 09:55:00 +0000

Estimates sound like a simple, beautiful, thing no project should ever be without. As always, if something is too good to be true, it is not true. Having a detailed estimate up-front for something highly uncertain is desirable, and impossible.

Estimates are hard to use properly, and very hard to get value from. There are people who understand probabilities, have a good grasp of variability and resulting deviations. These people are able to work with, and to benefit from, early estimates while considering all the uncertainty of the situation. These people also do not exist in IT project-planning roles.

Estimates look like a wonderful thing to have, but they are hardly necessary. Not having a good estimate may be less than ideal, but never disastrous. Estimates do not change the flow of work to the better, although they could encourage cutting corners. Many projects have been successfully completed without any estimates, or with bad ones.

Overall, the most desirable estimates are impossible to get right, all estimates are easy to misuse, and even the best estimates provide limited value even if everything goes well. Estimates are normally discussed in terms of a best-case scenario, which is very different from what usually happens.

Best case scenario

On-point estimate. All necessary resources available when needed. No changes in requirements.
On-time and on-budget delivery.

What usually happens

Best-case scenario estimate, further shortened because of business need. All necessary resources are not available until much later, except a few, that are not available at all. Massive and conflicting changes in requirements.
Complete chaos when estimated delivery date arrives.

Estimates are a nice thing to have in a perfect world. Having good estimates allows to predict far ahead of time when and what resources will be needed, when and what milestones should be completed, and when to expect the final delivery. However, in a perfect world, resources are available quickly, milestones are hit reliably, and delivery has perfect timing - whether there were estimates or not.

Real world is far from perfect. In the real world, more often than not, estimates are way off, inputs are late, milestones keep changing, and final delivery turns out to be a first draft. The only piece that remains set in stone is the original estimate, while the rest of the situation changes dramatically. Rough guesses become deadlines, do-or-die commitments, and the cornerstone of blame-passing culture.

For those projects that attempt to succeed in the real, rather than perfect, world, consider doing away with the estimates-come-deadlines.

For hard projects, choose Agile

Jane Prusakova — Tue, 17 Jun 2014 23:52:00 +0000

What’s the cheapest way to build software?

Agile approach is expensive. There are meetings that take valuable engineering time. There are non-engineering roles, i.e. people that need to be paid, that are not writing code and, therefore, whose contribution to the product comes into question. There is a significant body of test code, and which is obviously not helpful to the end user. There is constant refactoring work as the team discovers better architecture for the emerging product.

Waterfall is cheaper. Only hire an architect to for the initial phase of designing the system. Pay the technical team just to write the code for user functionality, and to do it quickly. The engineers can be cheaper, too, since all the thinking has already been done in the earlier design phase. Let the engineers go once all the code is written. Next QA comes in, runs tests, and violá, the product is done. No meetings ever needed, since all the people involved are working off the earlier phase’ documentation.

Why pay more?

Agile process has no single point of failure. Fault-tolerance of the process is extremely high, error detection and recovery is “baked in”. Waterfall, in contrast, requires perfect execution at every point in the process, i.e. every point is a single point of failure. Errors are hard to detect until the very end, and even harder to fix. As projects get more complex and require more investment, it makes sense to place a higher value on the probability of success, rather than on minimizing initial cost.

"Slowly and carefully"

Jane Prusakova — Sat, 31 May 2014 00:03:00 +0000

I once asked a coworker with an official title of Senior Software Architect, how he makes decisions and gives recommendations on the architecture of our product. “Slowly and carefully”, he replied. He was an honest and hard-working person, a very smart guy, and probably a decent architect. Yet our product’s architecture was terrible, and it was not improving as time went by.

Two deadly sins of software architecture were ubiquitous in our code base

Everything was tightly coupled with everything else
Same information was defined in multiple places

In day-to-day work these problems caused lots of hard-to-trace bugs, showing up in seemingly unrelated portions of the code. Changes required touching lots of code, leading to more bugs. And it was very hard to write tests – so tests were not written.

So, what was my colleague doing wrong? The architectural changes he and the team inflicted on the code base were fine - mostly because very little changes were made. There was no opportunity for a serious refactoring effort to improve on the underlying structure. The bad stuff that accumulated over time continued to accumulate. The new features represented good ideas, but were poorly implemented – or, rather, were implemented in much the same way as old ones, creating more bad code.

Looking back, there was a culture problem with the approach of “slowly and carefully, with no objective criteria, teamwork, or testing”. The architect did not write code. He provided suggestions that were implemented by other people. Programmers wrote code per instructions, and did not create tests to fully exercise the added or modified code. The architect did not have the feedback on how well his ideas fit into the code base, and programmers had very vague feedback on how their changes affected the system.

Most of the time, the architect's solutions were fine. He was familiar with the code, has been on the project for a long time, and knew the team well. But since his suggestions were hardly ever challenged, and never tested against competitive ideas, it is impossible to tell whether what he offered was really good - or barely good enough.

Every so often, a developer would complain that the solution suggested by the architect did not work, and it became a point of pride for others to write some “clever” code to fit the square peg (architect’s suggestion) into a round hole (existing code). It is well established that the “clever” code is more bug-prone and harder to maintain, compared to straight-forward and easily readable code.

Sometimes, no amount of cleverness could fit a new elegant idea into the clunky existing code, and then people improvised on their own. Most of the time, those were good, solid solutions, but not always. There also was an illicit feel to the situation, and some developers tried to avoid code reviews in these cases. There were a few scary monstrosities quietly sneaked into the code base as a result.

Splitting the implementation and design work prevents everybody from learning from their successes and mistakes. Having an architect dictate unchallenged solutions creates sub-par performance, tension and funny feelings even on the best-intentioned team.

Data Integration Tests and Transactions - Part 2

Todd Meinershagen — Sun, 25 May 2014 20:47:00 +0000

2014-05-25_data_integration_tests_and_multiple_data_framework_transactions

Last time I talked about how to use the TransactionScope class to handle the rollback of any changes made during a data integration test. This time, I would like to talk about another issue that will eventually come up using transactions: using Entity Framework code-first in combination with any other data access framework while leveraging TransactionScope.

In our case, we use Dapper to insert data before our tests and to assert things about the state of the database after exercising the code-first Entity Framework data layer functionality we are testing. Below is our example.

private TransactionScope _scope;

[SetUp]
public void SetUp()
{
    _scope = new TransactionScope();
}

[TearDown]
public void TearDown()
{
    _scope.Dispose();
}

[Test]
public void test_to_demo_ef_and_dapper_connections()
{
    var person = new Person {FirstName = "Todd", LastName = "Meinershagen"};
    var sql = "INSERT INTO dbo.Persons (FirstName, LastName) ";
    sql = sql + "VALUES (@FirstName, @LastName)";

    using (var connection = new SqlConnection("a connection string"))
    {
        connection.Execute(sql, person);
    }

    var db = new PersonContext();
    var matchingPersons = 
        from p in db.Persons
        where
            (p.FirstName == person.FirstName) &&
            (p.LastName == person.LastName)
        select p;

    matchingPersons.FirstOrDefault().Should().NotBeNull();
}

Both Dapper and EF establish their own connections, and we would expect that each connection would take part in the ambient transaction being created during the [SetUp] of our test fixture.

Normally, this is not an issue, but when the tests are run, we get a message similar to below:

MSDTC on server 'servername' is unavailable.

This can occur for any number of reasons such as the following:

Opening multiple connections with same connection string to SQL Server 2005.
Opening multiple nested connections with same connection string to SQL Server 2008.
Opening multiple connection to two different SQL Server 2008 instances.

In the case of our tests, we are making two connections (one for EF and one for Dapper) to SQL Server 2008 using the same connection string. Based on the guidance above, this should not force our system to escalate to MSDTC.

So, what is happening here?

After searching diligently on the internet (thank God for the internet!), I found an article explaining that Microsoft cleverly adds information to a code-first connection string to allow Microsoft to collect statistics from those using Azure and Entity Framework to determine what percentage use code-first as opposed to database-first. (Why Microsoft, why?) This is supposed to have been fixed in EF 6.0.

So, instead of using a connection string as you specified:

Data Source=(local);
Initial catalog=LocalDb;
Integrated Security=True;

The system uses the following for EF:

Data Source=(local);
Initial catalog=LocalDb;
Integrated Security=True;
Application Name=EntityFrameworkMUE

So, what does this mean?

Unfortunately, this causes our system to see the two connections (Dapper and EF) as two different connection strings and therefore, it looks like you are connecting to two different data sources which escalate to MSDTC. What a pain!

So, how do we get around this issue.

One way would be to use EF for both production and test code, although this robs us of the benefit of quickly setting up data using a light-weight framework like Dapper. Another option is to modify our test project’s configuration file by explicitly specifying the Application Name for our connection string. The system will then see the two connections as the same. No more escalation to MSDTC!

Hope this helps.

Data Integration Tests and Transactions - Part 1

Todd Meinershagen — Fri, 23 May 2014 02:31:00 +0000

2014-05-25_integration_tests_and_transactions

I have been writing some integration tests in .NET lately to specify behavior for my data layer. The issue that always comes up is how to make sure that each test is completely isolated from other tests. This requires each test to initialize needed data and at the end to clean up any data that was created so that other tests are not impacted by it. In the past I have set up compensating queries to delete that same data on tear down.

This can create one of two problems:

maintainability - it is hard to maintain this logic going forward
reliability - it doesn’t guarantee successful rollback of the initial inserts because the query could possibly fail leaving the tests in a position for unsuccessful future tests against the database

So, what do you do?

I have been using the handy TransactionScope class to allow any connections to participate in the ambient transaction and then dispose of the transaction without committing on tear down of the fixture.

In the example below, I have used NUnit, but this could work with other testing frameworks quite well.

[TestFixture]
public class MyFixture
{
    private TransactionScope _scope;

    [SetUp]
    public void SetUp()
    {
        _scope = new TransactionScope();
    }

    [TearDown]
    public void TearDown()
    {
        _scope.Dispose();
    }

    ///<summary>This is a silly sample test for display purposes only.</summary>
    [Test]
    public void given_context_when_something_happens_should_have_expected_outcome()
    {
        ExecuteSomeLogicForInsertingDataForContext();

        RunSomeActionToMakeSomethingHappen();

        AssertThatSomeExpectedOutcomeOccured();
    }
}

You could make this an abstract base class and make the SetUp and TearDown methods virtual if you would like to reuse this across any of your data test fixtures. As long as you don’t call _scope.Complete() the changes you have made should be rolled back/aborted on the disposal of the transaction.

Hope this helps!

Magic-8 ball, and other approaches to problem-solving

Jane Prusakova — Thu, 15 May 2014 11:27:00 +0000

There is a complicated way to do complicated things. Think long and hard. Spend hours staring into the blank space, screen or a sheet of paper or a list of specifications, or what-have-you. Then spend more hours furiously typing or writing or arguing out loud, while pacing nervously. Grab heavy, plain-jacket books with no pictures and very small font, throw them around. Doodle, draw up UML charts, and write down dozens of numbers… Do all of the above in freshly dry-cleaned business attire, or PJs, or worn-out jean shorts, or nothing at all. Repeat until half hour before the deadline. Feel very excited about the results.

This is pure magic. It is shrouded in mystery and emotion, takes magical amounts of time, and delivers unpredictable results with unknowable certainty. When it succeeds, it triumphs heroically, and when it fails, it does so with a big loud bang.

There is also an easier way. Make up something, anything, however wrong it may be. Devise a test, and perform it. Go back to the drawing board, the text editor, the spreadsheet, etc. Notice the problems in the previous idea and implementation. Then try again, taking the new information into account. Update the test as well. Continue until happy with the results. Heavy books, typing furiously, and worn-out jeans may still come in handy, but this way those are means to an end, not a pure expression of experiencing a difficult and unfair world.

When a complicated problem is solved by taking a small step at a time and adjusting, there emerges a combination of two possible solution paths. One path is as expected: iterating over small steps leads to a locally optimal solution. The achieved solution is local to wherever the initial, the least educated and therefore the most random, guess happened to be. In a lot of situations, this is good enough: achieved solution is proven to fit the problem by a series of tests, it is achieved in a reliable and predictable way, and no magic is required.

The other path is less expected, but nevertheless fairly common. Making small steps in the possible solution space allows to build an intuition about the underlying patterns and relationships. In addition to a set of concrete, tried-and-tested solution points, there emerges a deeper understanding of the problem. This leads to an intuition that allows to escape the local maximum, and helps reason about the entire solution space. Furthermore, a test-driven approach gives additional freedom to try out and gain confidence about further-fetched ideas in a systematic way.

The iterative approach is simple, rational, and pragmatic. It succeeds routinely and quietly, and fails rarely and cheaply. Magic may still happen, but it will be more grounded and less dramatic. More importantly, magic is not a requirement for success.

How magical do you want your problem-solving to be?

Improving Blogs

Scrum master woes

The scale of possible compromise solutions

What are coarse-grained estimates?

The Scrum Gauntlet of Debt

Lack of women in technology industry starts early

Spreadsheet Craftsmanship

Timing

Overview

Preparation

Overview of the Game

Round 1

Round 2

Round 3

Learning Points

Discussion and Facilitation Guidance

Link to Game

The Bicycle Game

Goal

Timing

Materials

Instructions

Preparation

Execution – Information gathering

Execution – Deep dive into causes

Execution – pick actions

Learning points

Think about your posture on your next interview – TED Talk

Make your code reviews Agile

One Word Retrospective Game

Retrospective darts

GeekMeet Networking, Aug 12th @ The Londoner

Penny Flow

Successful remote teams

New Blog

Agile Scrum framework at glance

More Meaningful Stories

Scrum in TV shows and in real life

LinkedIn Talent Article – 5 things recruiters do that drive candidates crazy

1. They don’t keep candidates up-to-date

2. The hiring process is sloooooooow

3. They don’t give straight answers

4. They reach out despite knowing nothing about the person

5. They don’t know the job. At all.

Weekend Escape an agile backlog management game

Agile Clock

Texas – Hot Job Market

ODE - Outcome Driven Enterprise - The Mindmap

How to work with a Recruiter

A story of one code review

Are we having fun yet?

Empowering Agile teams: culture clash. Part II

Good Agile teams break the rules

Myths and half-truths about estimates

The human side of enterprise

Simple solutions to complex problems

Never talk to strangers

Happy Hour – Geekmeet – October 22nd

The "family" objection

Discussion about good code at DallasTechFest 2014

New Opening: Sept 14th – Windows Systems Engineer – DFW Airport area

Dallas TechFest 2014

Dallas TechFest – Oct 10th @Gilleys in Downtown Dallas

Visual Studio 2013 Quality Tools

Stretch your mind

“The more you know,the more you realize you know nothing.”– Socrates

Improving Enterprises – AgileDotNext – Aug 22nd in Houston

Two are better than one

More Agile smells

Empowering Agile teams: culture clash

Calendar App – Mynd

Everybody wants a pony

Estimates in the real world

For hard projects, choose Agile

"Slowly and carefully"

Data Integration Tests and Transactions - Part 2

Data Integration Tests and Transactions - Part 1

Magic-8 ball, and other approaches to problem-solving

“The more you know,
the more you realize you know nothing.”
– Socrates