Agile Cooperative

New to agile? Remember, sometimes things get crazy!

Bob Hartman — Tue, 27 Jul 2010 20:50:34 +0000

Do you ever get so frustrated you feel like pulling your hair out? I do (although that is NOT a picture of me to the left!). If you look at my pictures you will see that it would be difficult for me to pull my hair out because a) there isn’t a lot of it, and b) what little there is I have cut very short. But, enough about me, back to the issue/craziness at hand.

I last updated my blog on June 14 and here it is July 27. That is way too long between updates, so let me start by apologizing to all of you who look forward to reading entries when I post them. Fortunately, during the time when I haven’t been updating the blog I recognized a problem which I often see on agile teams – CRAZINESS! Yes, sometimes things get a little crazy, or in my case recently, a LOT crazy!

My last month has been extremely busy. Since June 14th I’ve been in San Diego (twice), Minneapolis (twice), and Philadelphia. I’ve also sent out 8 training or coaching proposals, been on 18 conference calls, attended 3 major springboard diving meets with my son, one of my daughters had her gall bladder removed and my brother visited to do 10 days of handyman repairs around my house! In my calendar I see that I did all those things, but it still amazes me that they all got done. What didn’t get done? Well, this blog for one thing!

Why is it important to point out my “lack of dedication” to the blog? Because the answer is much more interesting than “lack of dedication.” In fact, I love writing blog entries. It isn’t lack of dedication at all, but rather lack of time. I made a conscious decision to do other things rather than update the blog. Why? Because I work in an agile way, and when I prioritized my backlog of work it caused writing blog entries to fall near the bottom of the list.

I often see agile teams saying things like “we can’t get it all done” and then they try to do the impossible. The result is usually ugly as they cut corners to try to make everything fit after saying it wouldn’t fit. Instead what these teams need to remember is to continue to honor their prioritized product backlog. Work on the important items and don’t spend any energy working on items that aren’t important. For me, not writing this blog was a tough decision. Writing here is a bit like therapy for me. However, for the past 5 weeks I’ve had to put it on hold because other things were much more important. Will I have dry spells like that again? Probably, but when it occurs it will occur because I’ve made a decision to prioritize other things higher on my backlog.

Good agile teams need to remember that things WILL get crazy. It is during the periods of craziness that the discipline of their approach works in their favor. Don’t fall back into old habits when the pressure or craziness starts to get out of control. Go back to basics and continue to work in priority order. Working faster usually leads to more errors. Working diligently in priority order will always outperform working “faster” on everything at once.

Until next time I’ll be Making Agile a Reality^® for my clients by continuing to prioritize my work and personal life in a way which will lead to a balance where I can deliver maximum value to everyone.

Related posts:

New to agile? Remember how to say “No” No. Only two letters. Very simple word. Yet for some reason, with...
New to agile? Remember to respect people One of the Lean Principles is “Respect People.” I think it may...
New to agile? Remember the power of automation As this blog entry is published I am teaching an agile/scrum course...

Do You Believe in Coding Standards?

David Bernstein — Wed, 21 Jul 2010 20:18:21 +0000

I am told that some developers don’t like coding standards imposed on them. I do not have that experience. In working with thousands of developers I notice that they prefer following standards as long as it supports them in doing a good job.

We all hate busy work or pointless activities. If your coding standard is to have a comment for every line of code, like it was for me when I worked at IBM 20 years ago then developers may not follow it because it is _stupid_.

But coding standards that support the team are often quickly assimilated if all the team members see the benefit. However, we may not see the benefit because it wasn’t described to us correctly. For example, one of the most valuable practices I teach is encapsulation of construction. Most developers are familiar with the concept but perhaps never saw the benefit of using it because it wasn’t explained to them well.

It seems like every time you turn around someone has a new tool or methodology or something that is supposed to revolutionize our industry. No wonder seasoned software developers have become jaded. We often find what works for us and stick to it. We resist the flavor-of-the-month methodology because we’ve seen too many come and go.

But since we work in such a fast changing industry we have to reevaluate our knowledge on occasion so we continue to learn new things. This is true for other fields as well. Most M.D.’s spend at least 12 hours per week reading journals. Even CPA’s are required to get several days of training each year in order to renew their license. We developers have to be even more vigilant.

Just Enough Regular Expressions for Cucumber

Richard Lawrence — Tue, 20 Jul 2010 21:38:50 +0000

Jon Archer wrote last week about how Cucumber makes knowledge of regular expressions important. He’s right: Regular expressions are the key to Cucumber’s flexibility. Well-crafted regular expressions let you reuse step definitions, avoiding duplication and keeping your tests maintainable. But even experienced developers find them mysterious and overwhelming.

Fortunately, you don’t need regular expressions like this one to wield the power of Cucumber:

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

In fact, if you use regular expressions like this in your step definitions, you’ve gone too far. (This regular expression, in case you’re wondering, matches the official spec for valid email addresses.)

As with most things, the 80/20 rule applies. There are a handful of useful patterns that are sufficient to make you a Cucumber power user.

Anchors

The regular expression I'm logged in matches I'm logged in and I'm logged in as an admin. To avoid ambiguous matches, use ^I'm logged in$.

The caret at the beginning anchors to the beginning of the string. The dollar at the end does the same with the end of the string. Use these with all your step definitions and you won’t have surprise matches.

Wildcards and quantifiers

Matching specific words is fine. But you often want flexibility to match a variety of strings. Here are some common patterns for non-exact matches.

`.*`	matches anything (or nothing), literally “any character (except a newline) 0 or more times”
`.+`	matches at least one of anything
`[0-9]` or `\d`	matches a series of digits (or nothing)
`[0-9]+` or `\d+`	matches one or more digits
`"[^\"]*"`	matches something (or nothing) in double quotes
`an?`	matches a or an (the question mark makes the n optional)

Capturing and not capturing

When you put part of a regular expression in parentheses, whatever it matches gets captured for use later. This is known as a “capture group.” In Cucumber, captured strings become step definition parameters. Typically, if you’re using a wildcard, you probably want to capture the matching value for use in your step definition. Here’s a Cuke4Nuke example,

1
2
3
4
5

[Given(@"^I'm logged in as an? (.*)$")]
public void ImLoggedInAsA(string role)
{
// log in as the given role
}

If your step is Given I'm logged in as an admin, then the step definition gets passed "admin" for role.

Cuke4Nuke converts captured strings to the step definition parameter type, which is handy for step definitions like this:

1
2
3
4
5

[Given(@"^I have (\d+) cukes$")]
public void IHaveNCukes(int cukeCount)
{
// set up the given number of cukes
}

The step Given I have 42 cukes means the step definition gets called with 42 (as an integer) for cukeCount.

Sometimes, you have to use parentheses to get a regular expression to work, but you don’t want to capture the match.

For example, suppose I want to be able to match both When I log in as an admin and Given I'm logged in as an admin. After all, both step definitions do the same thing. There’s no reason to have duplicated automation code in my step definitions simply because one is a Given and one is a When.

I might write something like this:

1
2
3
4
5

[When(@"^(I'm logged|I log) in as an? (.*)$")]
public void LogInAs(string role)
{
// log in as the given role
}

The parentheses and pipe indicate a logical OR, just what I need to match two different strings.

This will fail to run, though. My regular expression is capturing two strings, but my step definition method only takes one. I need to designate the first group as non-capturing like this:

1
2
3
4
5

[When(@"^(?:I'm logged|I log) in as an? (.*)$")]
public void LogInAs(string role)
{
// log in as the given role
}

Now, with the addition of ?: at the beginning of the group, it will perform as I expect.

By the way: You may be wondering how the attribute can be When and still match Given I'm logged in as an admin. It turns out that in Cuke4Nuke, just like in Cucumber for Ruby, it doesn’t matter whether you use Given, When, or Then to define a step definition. They’re all step definitions and are interchangeable. It’s fairly common for today’s When to be tomorrow’s Given, so this is a nice feature.

Just enough

This is only the tip of the regular expression iceberg. Here’s a book and website if you’re interested in going deeper. But for day-to-day work with Cucumber, anchors, simple wildcards and quantifiers, and capturing and non-capturing groups are all you need.

Compromises on Quality

David Bernstein — Wed, 30 Jun 2010 16:12:40 +0000

Far too often I hear managers say, “Just get it out the door.” I understand the perspective. We work in a world of constraints and the business needs to survive.

Management often says this but really mean “I look to my developers to tell me what critical things must be there in order for the business to derive benefit.” If we are being asked to deliver something with such low quality that the customer or the team will pay for it later then we must help management understand the cost of their decisions.

We are not looking for perfect code. Building software is a series of compromises and the developers who are writing it are the best informed to make the wisest decisions on which compromises to make.

We all want to be proud of our work but we also realize that being a perfectionist is often not desirable and we must find a middle ground. Sometimes we have to ship code with serious flaws but we should be aware when we do and make a case for cleaning it up later as good for the business’s ongoing investment in their software assets.

New to agile? Learn how to fail well

Bob Hartman — Mon, 14 Jun 2010 17:22:10 +0000

Is success or failure really a choice? I don’t think it is at all. Pretty much no one chooses to fail. Unfortunately, we can’t just choose to be successful either. What we CAN choose is to try to make a success out of a failure! The old saying “Make lemonade out of lemons” really is a good way of looking at things, especially for agile teams.

Agile teams will have times when they “fail.” I know a lot of people dislike using the words “fail” and “failure” when talking about team results. I’m actually pretty tired of that argument because I don’t think it helps anyone. I’d rather call a “poor result” a “failure” and acknowledge we can and will strive to do better next time. As I say during workshops I facilitate, “I am blunt and reality based. Sometimes that means I will say things which you won’t like to hear.” I don’t call teams “failures” or anything like that. That would be namecalling and that is never appropriate. However, calling results a failure is correct and leaves no room for interpretation. I find being blunt in those situations to be more useful because teams then must face the reality and not try to sugar coat it as “not being all that bad…”

What comes out of failure is what I care about. I don’t care so much how it happened, why it happened, who supposedly caused it to happen, or that it wasn’t all that bad really. What I care about is acknowledging there is a problem that needs to be solved. In my experience I find it easier to digest and solve if failures can be limited to happening only if 3 conditions can be met:

Conditions for acceptable failure

Fail FAST!
Learn from it.
Don’t do it the same way again.

Teams which keep these three simple conditions in mind when dealing with risk they often find themselves making better decisions and reacting more appropriately to the results of those decisions. The areas of highest risk are where we are most likely to encounter failure, so how will we limit the timeframe to failure? If we fail, what will we learn from it? If we fail, how will we avoid failing in the same way again? This is the heart of improvement. Be open and honest about the result (failure). Limit the damange (fail fast). Examine the failure closely (learn from it). Try a new way to solve the problem (don’t do it the same way again).

I see too many teams accepting failure time after time after time. It is very frustrating to the organization and sometimes the team doesn’t even acknowledge there is a problem. They keep saying they can’t do anything about it or it is an “acceptable failure.” What does that even mean? Acceptable to who? Last time I checked, none of my clients were particularly pleased about failures. This is where it gets dangerous to call a failing result anything but failure. Calling it something else makes it somehow more palatable and easier to ignore. Getting past difficult failures is the time of greatest learning and improvement for teams. It changes regular teams into high performing teams, and high performing teams can become hyper-productive teams.

Don’t blow failures out of proportion (it really isn’t the end of the world), but at the same time don’t ignore them either. Teams must deal with failures and turn them into successes downstream. If they don’t do this then the failures will continue to cascade and cause a loss of morale, loss of urgency and ultimately a project or organizational failure. Not dealing with failure is leaving a fuse lit on a ticking time bomb – I hope you defuse it in time!

Until next time I’ll be Making Agile a Reality^® with my clients by continuing to make sure they all understand the 3 conditions necessary for failure to turn into eventual success.

Related posts:

Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it? The team finished the iteration...
Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...

Paul Rayner Joins The Agile Cooperative

Richard Lawrence — Fri, 04 Jun 2010 11:17:02 +0000

I’m excited to announce that Paul Rayner’s company, Virtual Genius, has joined The Agile Cooperative. Paul is the founder and president of the Denver chapter of the International Association of Software Architects (IASA). I’ve known him for the last couple years through IASA and Agile Denver.

On top of a great Australian accent, Paul brings to the Cooperative expertise in agile architecture and engineering practices. Earlier this year, Paul and I co-taught and consulted on Acceptance Test Driven Development with Cucumber. I’m very pleased to formalize what is already a great partnership.

Learn more about Paul on the Virtual Genius blog. Or subscribe to the combined Agile Cooperative feed to get new blog posts from all the Cooperative members.

Slides from Portland Code Camp 2010

Rod Claar — Fri, 28 May 2010 17:20:09 +0000

I had another great time at the Portland Code Camp this year. My first talk had about 35 attendees and then the second one was SRO at close to 50.

Here are links to my slides.

Agile Analysis for Developers

Agile Architecture for Developers

Two Seminars at Portland Code Camp 2009 Two of our most faviorite talks have been...
PDX Code Camp 2009 This year was my first at the PDX Code Camp,...
Professionalism in Software Development Robert (Uncle Bob) Martin talks about Professionalism in Software Development...

Clearing the air on Scrum Alliance Registered Education Provider Program

Rod Claar — Fri, 28 May 2010 14:57:59 +0000

There have been a lot of negative comments about the new Scrum Alliance Certified Developer program lately. One web post referrs to the organizers of the program and presmuably the participants as “festering money-grubbers” .

Let me clear a couple of things up about the CSD program. For full disclosure, I’m on staff with the Scrum Alliance helping administer the program.

Firstly, focusing on the CSD is a little short sighted. Certified Scrum Developer is the first training program in the new Scrum Alliance Registered Education Provider program (SA-REP) http://www.scrumalliance.org/SA-REP. The Scrum Alliance is seeking applications from training organizations that have something to offer the Scrum community. There are 10 organizations listed right now and several more are in the final stages of approval, including a branch of a major university. These organizations are screened for experience and demonstrated expertise in developing and administering training programs. The application process also reviews the resume of each course designer and trainer submitted by the applying organization. Lastly each course is reviewed relative to the leaning objectives for the program. Once a new SA-REP is approved and they have approved courses and trainers they are given the ability to list public courses on the Scrum Alliance site.

The SA-REP program is also setting up to assess and review the courses and trainers that deliver training in the program. The details of how this will be administered is still under development, however the goal is to help improve the quality of training and give students they information they need to select training that is valuable to them.

The CSD program is an SA-REP program. Every SA-REP that submits a course and trainers for CSD-Eligible status are reviewed as I described. The program includes Scrum knowledge as well as an aggressive set of technical learning objectives for developers working on Scrum teams. These include the practices of Test-First, Test Driven Development, Continuous Integration, Agile Analysis and Agile Architecture.

So far we have 2 Java based programs approved and one .NET. We have applications currently being reviewed for Ruby and another Java program. There are training opportunities currently available on four continents.

With the massive improvements in Visual Studio 2010 and the new Application Lifecycle Management abilities of the new Microsoft Tools the Scrum Alliance is seeking qualified and experienced trainers on the platform. This why the application asks if the trainer is qualified in this area thought the programs listed. The application process reviews the Scrum training ability and experience of all applicants and if any trainer does not have demonstrated experience in Scrum, the Scrum Alliance will work with the organization to partner with an experienced Scrum trainer to help them with that part of the program.

BTW, I don’t see any “festering money-grubbers” listed as SA-REPs. Who are you referring to? I see qualified, experienced training organizations offering much needed training for developers and other professionals working on Scrum teams.

If you have any other questions about the SA-REP or CSD programs, feel free to contact me directly.

Rod Claar
SA-REP /CSD Program Community Liaison
rclaar@scrumalliance.org

INDUSTRY VETERAN ROD CLAAR JOINS RIPPLEROCK TO LEAD THE NORTH AMERICAN AGILE PRACTICE RippleRock recently recruited industry veteran trainer and Agile Coach Rod...
Scrum Video Scrum Music Video!...
Scrum is a flexible process! Most organizations reacquire a tool to help manage complex distributed...

Who is Our Customer?

David Bernstein — Wed, 19 May 2010 21:41:44 +0000

Have you ever stay up until three in the morning trying to track down a bug? Maybe it was code that you were charged with maintaining or maybe it’s something you just wrote. Remember how it felt trying to figure out what the author was doing?

Who is our customer? You may think it is the person who uses our software and they are very important but we have another customer we sometimes forget, you—that you that is trying to fix a bug at 3:00 am. The people who maintain our code are also our customers and we must write software for them as well.

When we consider that over 80% of the total cost of software happens after it is released we can see that maintainability of software is critical to success and that we must drive the cost of ownership down.

Our software must do the right thing but just correctness is no not enough. The code that we write must be easy to understand, maintain and extend. But how do we do this? What makes software easy to understand, maintain and extend? This is what we will look at in upcoming posts so stay tuned.

Agile antipattern: Target fixation

Bob Hartman — Tue, 18 May 2010 18:35:49 +0000

Have you ever been so focused on something that the rest of the world seemed to disappear for a while? This can be great under certain circumstances, but in other cases it can be extremely harmful. When someone focuses on a target and doesn’t see anything but the target we call it “target fixation.” This can have dire negative effects! For example, a fighter pilot can become so fixated on a target that they forget to avoid the target and run right into it. The same can happen as we go through a curve in a moving vehicle.

Unfortunately, a variation of this can also occur to agile teams! When it starts happening to agile teams it can be very difficult to detect and correct because everyone thinks they are doing the right thing. It isn’t until much later when most teams finally determine this was the problem.Let me start by giving a few things I think happen when agile teams are too fixated on the target:

It becomes vital to “hit the date” or “hit the story point goal” or whatever other goal is laid out. While this is not inherently bad, when combined with some of the other items below it may be indicative of a problem.
The team starts to cut corners on quality in order to hit the goal. This is done subconciously in most cases. Teams simply write fewer and fewer tests. Especially automated tests.
Risks and impediments are no longer raised in meetings. After all, dealing with them may cause the team to miss the goal.
Team members work more overtime hours – all in the interest of getting to the goal “just this once.” If it happens more than once it is time to take notice.
Team members start to silo rather than collaborate and communicate openly. “If I can just stay heads down I can finish this” becomes a pervasive attitude.
The team starts to think about dropping the daily stand-up meeting so they have more time to reach the goal.
Retrospectives turn into blamestorming sessions.
The team starts to miss obvious problems until it is too late in the iteration to do anything about them.

If your team is starting to suffer from more than a couple of these items you should take a step back and see if the goal has become more important than doing the right thing. I tell my classes “Do the right thing and trust that the right things will happen as a result.” Starting to do the wrong thing will not magically make the right results appear – except as a mirage. Sacrificing something good will always lead to an issue further downstream. Don’t fall into the trap of thinking you can get away with it!

If a team is starting to overly focus on “the goal” to the detriment of doing the right thing then someone needs to step up and say it! This is where the Scrum value of having courage comes into play. If someone doesn’t have the courage to stand up and say it is broken then nothing will ever get fixed. Teams can spin in this cycle for a long time if no one notices the problem. On occasion a team in this mode will make all of their iteration commitments along the way and then have massive rework to do at the end. No one ever traces it back to making the goal more important than doing the right thing.

Focus on doing the right thing, inspecting the results and adapting. This is the only way to improve and reach real goals in realistic timeframes. Some good reference blog entries to read would be:

Hopefully your team isn’t overly fixated on the target, but if they are, get it fixed ASAP!

Until next time I’ll be Making Agile a Reality^® by pointing out to teams when they are too concerned about the wrong things (which all too often seem like the right things)!

Related posts:

Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
Agile antipattern: But the development lead said it would take way less time than that I’d be rich if I had a nickel for every time I’ve heard...
Agile antipattern: Treating symptoms not causes Agile teams often get to a point where they have a number...