What Type of “Done” are You? This is certainly one of the central questions of Scrum. Does it involve testing, integration testing, user acceptance, documentation, or all of these?

It is up to you – as a company – to define what Done means.

A “done” task at the end of a sprint means it is a fully working and shippable increment of the product, and it is an increment you want to built upon in your subsequent work. The size of the task “done” does not matter much, it can be small as long as it is “done”, according to the definition. So better do it well or it will show up again later in your backlog and retrospectives …

Questions like these – all focused on the core aspects of the Scrum methodology – were discussed at the ScrumMaster certificate workshop at the Entwicklertage Karlsruhe [http://www.andrena.de/Entwicklertag/2010/], 21.-22.6. One of the godfathers of Scrum, Ken Schwaber, was performing this workshop with around 30 people in the Schlosshotel Karlsruhe. Canoo was contributing well, providing 10% of the participants. The workshop was a lot of fun, full of exercises, jokes, anecdotes and insights.

Scrum is an empirical process and therefore requires some experience. Reading a book about it gives you an idea, but you have to practice and live it.

What do you think, does a Scrum Master have to be at the daily scrum meeting? That was an interesting question to discuss. On one hand, the ScrumMaster is directly accountable for the Scrum process by definition. Therefore he had better attend the meeting and help remove impediments. On the other hand, the purpose of the meeting is not to report to the Scrum Master. It is for the team to get an understanding where they are and what is going well or not.

Is it correct if management attends a Spring review meeting and applauds you for your success? What should you do if the product owner reshuffles the whole product backlog against your better knowledge? Given 20 Mio. Dollars to expand your company, how would you scale your initial team of 7 to 70? How do you write an offer based on the Scrum approach to a fixed business request?

Scrum is based on transparency and commitment, it establishes local predictability in highly complex and globally uncontrollable projects. It makes risks and defects highly visible. Its time to get rid of the “feature finish metronome” in our heads.

Some of the most important aspects we learned from the training were:

– deliver a shippable increment within each sprint, otherwise you have nothing to build upon

– select no more work then you can finish properly

– work on one thing at a time

– product owner must learn to demand less. Take it as an opportunity to focus on value not quantity

– when under pressure, drop low value items not quality

– people are able to form and manage their teams on their own

At one point, Ken made an interesting historical note about the early days of Scrum: It’s not that the world was missing the truth with respect to development. But what made Scrum possible was a change in development environments towards integrateable and automatically testable systems, a feature that first arose back in the days of smalltalk projects. Lucky for us, we were born too late…

Ken Schwabers concluded with the words: “I think we have one of the best profession one can imagine; do your best to transform it back into something enjoyable!”

Thanks Ken

What Type of “Done” are You? This is certainly one of the central questions of Scrum. Does it involve testing, integration testing, user acceptance, documentation, or all of these?

It is up to you – as a company – to define what Done means.

A “done” task at the end of a sprint means it is a fully working and shippable increment of the product, and it is an increment you want to built upon in your subsequent work. The size of the task “done” does not matter much, it can be small as long as it is “done”, according to the definition. So better do it well or it will show up again later in your backlog and retrospectives …

Questions like these – all focused on the core aspects of the Scrum methodology – were discussed at the ScrumMaster certificate workshop at the Entwicklertage Karlsruhe, 21.-22.6. One of the godfathers of Scrum, Ken Schwaber, was performing this workshop with around 30 people in the Schlosshotel Karlsruhe. Canoo was contributing well, providing 10% of the participants. The workshop was a lot of fun, full of exercises, jokes, anecdotes and insights.

Scrum is an empirical process and therefore requires some experience. Reading a book about it gives you an idea, but you have to practice and live it.

What do you think, does a Scrum Master have to be at the daily scrum meeting? That was an interesting question to discuss. On one hand, the ScrumMaster is directly accountable for the Scrum process by definition. Therefore he had better attend the meeting and help remove impediments. On the other hand, the purpose of the meeting is not to report to the Scrum Master. It is for the team to get an understanding where they are and what is going well or not.

Is it correct if management attends a Spring review meeting and applauds you for your success? What should you do if the product owner reshuffles the whole product backlog against your better knowledge? Given 20 Mio. Dollars to expand your company, how would you scale your initial team of 7 to 70? How do you write an offer based on the Scrum approach to a fixed business request?

Scrum is based on transparency and commitment, it establishes local predictability in highly complex and globally uncontrollable projects. It makes risks and defects highly visible. Its time to get rid of the “feature finish metronome” in our heads.

Some of the most important aspects we learned from the training were:

deliver a shippable increment within each sprint, otherwise you have nothing to build upon

select no more work then you can finish properly

work on one thing at a time

product owner must learn to demand less. Take it as an opportunity to focus on value not quantity

when under pressure, drop low value items not quality

people are able to form and manage their teams on their own

At one point, Ken made an interesting historical note about the early days of Scrum: It’s not that the world was missing the truth with respect to development. But what made Scrum possible was a change in development environments towards integrateable and automatically testable systems, a feature that first arose back in the days of smalltalk projects. Lucky for us, we were born too late…

Ken Schwabers concluded with the words

I think we have one of the best profession one can imagine; do your best to transform it back into something enjoyable!

Thanks Ken

Canoo meets Ken

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.

So you’re thinking about getting an IT certification? Congratulations, you have discovered the Pragmatic Programmer Tip #8 – “Invest Regularly in Your Knowledge Portfolio”. But before you sign up, pay your fee, and spend your time chasing a certification, consider two points from the fine print from the Pragmatic Programmer book: Manage Risk and Buy low, sell high.

I do not have a Java certification, despite it being my primary language. There is risk for me to get this certification… I might spend all my time studying and then fail the test! I don’t think “studied for the certification exam” looks as good as simply “I am certified”, but that’s what I might end up with after several weeks of work. And there is also the risk that I am buying high and selling low, instead of the other way around. The Sun estimate for getting the Developer cert is 160 hours! This is a huge investment and I am not sure I’ll recoup the cost quickly enough. Perhaps there are better alternatives? Is there something that offers just as much benefit but with less effort? Or more benefit with the same effort? If there is, then the decision on whether to get a certification or not is an easy “no”: it’s ain’t worth your time kid.

The following is a table of all the things I’ve done in the last 12 years and the amount of time it took me to accomplish them. If the numbers are accurate, then it should be fairly simple to make a cost/benefit analysis of different knowledge portfolio endeavors.

Task

Effort

Notes

In-House Tech Presentation

8 Hours

Your resume can either say “Spring” or “Trained team on Spring”. The latter looks a better and gives you a more interesting story to tell in interviews. At only 8 hours of prep and delivery time, this has been useful for me. Recommended.

User Group Presenter

24 hours

A user group presentation is stressful but not that hard once you’ve done an in-house presentation. It does take some effort though and I usually have to pay for travel. The problem is that this task doesn’t prove anything to interviewers that the in-house tech presentation doesn’t already do and in less effort. Unless you have ulterior motives (future conference speaker, egotism, community building) then I say Don’t Bother

Conference Presenter

16-32 hours

Once you’ve given a user group session then the conference session is pretty much a cakewalk. A stressful, nauseating, sweaty cakewalk. And there is definitely some cache with being a conference presenter. When I’m asked, “Do you know OSGi?” I get to answer, “I presented on it at 2GX.” and if you can speak for 90 minutes on a topic at a conference then surely you can go 5 minutes in an interview. Recommended* (*if you already gave a user group talk)

Open Source Contributor

8 hours

Being a contributor to a project is pretty darn easy, but your friends will probably care a lot more about this than someone who is interviewing you. I don’t think I’ll land any new jobs because of the 10 line patches I’ve sent a half dozen projects, but I did make some good friends. And you know what, the guy who recommended me for a job at Canoo was someone I had sent a 10 line patch to. But as an alternative to certifications, Don’t Bother, the benefits are intangible at best.

Open Source Committer

120 hours

If you take 3 weeks off of work and work solidly on an open source project, I think you’ll be made a committer. The problem is that people reading your resume frequently have no idea what the difference is between a contributor and a committer. And being a committer is a long term commitment to fixing bugs and remaining active. This is a lot of work but also a lot of fun. Being a Groovy committer has been greatly beneficial for me, but it was paired with conference speaking and blogging. I say Recommended* (*but it is really more of a lifestyle choice).

Open Source Project Lead (for your own project)

40 hours

If you are the only developer on an open source project that no one has heard of then nobody is going to care. I wrote TimeTool to learn Swing. Mission accomplished. But is is a terrible alternative to certification. Don’t Bother.

Administer a User Group

24 hours

Administering a user group tells interviewers you like distractions from coding and it won’t help you answer any of their interview questions. On the plus side, you will meet a whole bunch of people that will suggest your name for interviews. If you’re looking for a new full time job then this is a good tactic. If you’re looking to ace consulting gig interviews then Don’t Bother.

Certified ScrumMaster

16 hours

There is no preparation for the course, it is not too expensive, it never expires, and there is no test. This is about the easiest certification you’ll ever get. And a lot of hiring managers value this. If you want to learn and enrich yourself then skip this “certification”. If you want a certification on your resume, then 100% Recommended. You can get Scrum certified almost 5 times for the same investment as a SCJP, and with no risk of failing a test.

Webmaster for User Group

12 hours

I was the OTUG webmaster for almost 3 years. It was a nice way to make friends, but no one interviewing you will care about the plain old HTML and CSS site you maintain. As an alternative to certification: Don’t Bother.

Volunteer Conference Organizer

40 hours

As a volunteer conference organizer at Agile 2006 and 2009, I got to see the conference for free, I got to meet and engage the speakers, and I made some friends. Interviewers won’t be impressed specifically with the volunteer experience, but I have several good stories I can tell during interviews. And the 40 hours I spent was all time at the conference. Recommended.

Build Personal Website

40 hours a year

Unless your personal website is Slashdot or BoingBoing, then Don’t Bother. I’ve spent an inordinate amount of time editing photos, php, javascript, and css for something that facebook replaces for free. No one cares about this, not even my friends and family. Harsh.

Learn a new language this year

40-100 hours

I have 5 years Java experience. Plus Groovy and F# and Scheme, all learned during that time. How can I truly have 5 years Java if I spent my time learning other languages? Learning new languages is great for your mind and bad for your resume. As an alternative to certification, Don’t Bother.

Organize and run a Book study

16 hours

I organized or participated in about 6-8 book study groups in the last few years. It is a small investment, especially if you’re going to read the book anyway. And I can definitely say that reading and discussing Java Concurrency in Practice, Release It!, and Effective Java twice has made me a better programmer and interviewer. Plus, the interviewers will assume (rightly) that you can help their team run a book club, which you should do. Minimal investment, high value: Recommended.

Write a technical blog

40-60 hours

A blog post should take about 4 hours to write, and if you make 10-15 posts then you’ve got yourself a nice little blog. When interviewers see your URL in the resume they’ll click it and skim the contents but not read any of the articles. If you want maximum value for minimal investment, then do not date the articles and don’t supply a way to see how many posts there are… that way the site will age gracefully in the future. Cynical? Maybe. Other programmers will care about this a lot more than managers will care. I say: Consider It.

Master’s Degree

1344 hours and $$$$

This is a huge time investment, a big money investment, takes 3-4 years of calendar time, and won’t start accruing value until it is fully finished (no one cares that you are “taking” a masters degree only that you “finish” the degree). It is the ultimate un-agile training strategy and a good example of a bad value stream. Don’t expect monetary payback until almost 10 years after your first class! This is a bad alternative to certification because of the enormous cost: Don’t Bother.

And here is my guess about the Java certifications a few of us Canooies are considering:

Java Certified Programmer

80 hours

You study a large book. You possibly become a better Java programmer. You may study too much and waste your time studying or you may study too little and fail the test. However, the SCJP certification gets you in the door with a lot of companies and some people do care about this. This won’t help you perform in interviews, but it definitely helps get the interview. I have to say, after careful comparison, this ranks as a strong Consider it. The biggest problem is that it is just not fun to do.

Java Certified Developer

160 hours

Sun/Oracle says this cert should take 4 weeks of effort, but that seems like a high estimate. And again, you may do too much or too little work. Plus, interviewers may not know the difference between SCJP and SCJD! I predict most filters are looking for SCxx and don’t care about which level you actually have. Considering the time investment and risk, I say Don’t Bother.

And the results?

Here are some equivalent scenarios on how to spend the next 80 hours of your life:

Sun Certified Java Programmer (80 hours)

or all of these combined:

2 In house technology presentations (16 hours)

2 Open Source Contributions (16 hours)

Scrum Master Certification (16 hours)

2 Book Study Groups (32)

And you have fun doing it!

In my opinion, the latter list sounds better than the previous list. Problem is, my opinion doesn’t count for much when it comes getting in the door as a contractor or consultant. If you are looking for a new full time job, then I recommend that 2nd list and skip the Java cert. For contractors/consultants, it pains me to say it but the Java Certification still seems like a decent value for the cost.

So what is your custom plan this year? The first list or the second?

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.

This article originally appeared in the April 2010 edition of GroovyMag, the Groovy and Grails magazine. Parts 2 and 3 are currently available for download from the magazine’s site, and more will come each month. Enjoy!

The Groovy Programming Language advertises itself as an “agile and dynamic language for the JVM”, but what does this mean exactly? This series of articles explains Lean Software Development, and shows how your choice of programming language can make your entire process remain nimble and adaptive. Each month will cover one of the seven Lean Software Development principles and explain how Groovy and the associated ecosystem help eliminate waste, defer commitment, and build quality into your product.

About This Series

Most of your agile team will spend the majority of their day working with a programming language, making it one of the most important tools to optimize in your project’s life-cycle. Yet many organizations are reluctant to experiment with newer languages and frameworks, instead preferring to apply what works in one domain to all domains. They are skeptical about the claimed productivity gains from polyglot programming, concerned about the educational investment of retraining their developers, and worried about the risk of using less proven technologies.

Some languages are truly better than others for certain types of problems. These articles exist to help you identify which domains in your project are most in need of a little Groovy magic as well as to help you sell Groovy to a skeptical or unconvinced audience. Hopefully you will see that Groovy is a great fit for your software life-cycle: its dynamic and expressive nature brings greater productivity to testing and operational support, its closeness to Java minimizes educational investment, and its tight integration with the JVM platform allows you to slowly phase in Groovy without an all-or-nothing decision, making its use a low risk decision.

Groovy is an agile programming language. In order to explain what this means, these articles are structured around the seven principles of Lean Software Development. This month includes a short introduction to Lean, and you’ll see how an expressive language can eliminate waste in unit testing. Next month you’ll see how the easyb Behavior Driven Development framework builds quality into your software development life-cycle. Later we’ll explore how different testing tools like the Spock Framework help create knowledge, how a dynamic language lets you minimize coupling and defer commitment, and how metaprogamming allows you to deliver your software fast. In future installments you’ll see how Groovy’s Grapes module system, alongside modules like Groovy Web Services, streamline interactions between your development team and other groups like Operations and QA. Finally, we’ll look at how Groovy can be applied to domains that cross departmental boundaries: how Gradle improves the build process and easyb facilitates collaboration and communication between team members and other stakeholders. The series will end with a discussion of best practices when mixing Java and Groovy

Some of the code examples are basic while others are advanced. This series explores why the features of Groovy are important rather than the mechanics of any one Groovy feature. Hopefully you’ll leave with some new ideas about how to use Groovy, how to convince your team that Groovy is worthwhile, or most importantly how to increase your productivity.

Lean Briefly Explained

Lean manufacturing grew out of the influential Toyota Production System, which was a set of both philosophies and practices designed to weed out waste, inconsistency, and overburden from a manufacturing process. While the Toyota brand recently took a beating for some public quality failures, it is hard to ignore several decades of successful engineering sensitive product development. In the late 1990’s, Mary and Tom Poppendieck took their knowledge of Lean and applied it to a software project, eventually resulting in 2003 with the publishing of the excellent book “Lean Software Development”. The Lean principles have been revised over time; for our purposes we will use the seven principles from “Implementing Lean”:

Eliminate Waste

Build Quality In

Create Knowledge

Defer Commitment

Deliver Fast

Respect People

Optimize the Whole

Lean has been an influential movement within the agile community, spawning a plethora of books, workshops, and articles. Besides being a meaningful set of practices in its own right, it has also directly influenced other agile family Members such as Kanban Software and Real Options. Lean is a set of principles first and a group of practices second. The principles are specific enough to align a team but broad enough to appeal across an organization. I once spent a three-hour car ride discussing eliminating waste with the senior manager and director of my development group, and then arrived at work to help an eager development team make practical changes to reach the goals we had discussed. Compare that to a methodology with principles of “Honesty” and “Communication”. I have
yet to find a use for vague principles beyond their ability to make me feel a little better about a crummy process.

Principle 1 – Eliminate Waste

Taken literally, it is easy to see how Groovy fulfills the Lean mandate to eliminate waste: list and map literals, a terse closure syntax, and even a lack of semi-colons means there is simply less keyboard typing to do for Groovy developers. But that isn’t what Lean means by eliminating waste. The real waste within the software process is in half done work. Work that has been started but not delivered eats up the time investment from developers but does not provide value to the client. Any work that has been started but not completed is a form of waste, and we must optimize our life-cycle to keep our user stories out of this state! This means moving stories to Done faster, and any good agilista will tell you Done isn’t done until the unit and acceptance tests pass. Having used Groovy as a testing language on several projects in the last few years, my team’s experience is that the same test coverage and quality can be reached with Groovy in less time than it takes using Java.

Good unit testing means testing not just the success scenarios, but also the failure scenarios and the edge cases where things just barely pass or just barely fail (bugs do tend to congregate in corners, after all). This means your unit tests have to create data, and lots of it. Much more data than your production code needs to create. And Groovy is a language better optimized to create data than Java. Consider the data driven test in Listing 1.

Java

1

2

3

4

5

6

7

8

publicvoidtestSimpleMath(){

[4:{2+2},

6:{2+2+2},

8:{2+2+2+2},

].each{expected,actual->

assertexpected==actual()

}

}

Listing 1: A Simple Data Driven Test

The example shows a few ways in which Groovy is different from Java. Should read: First, a Map is declared using the notation [key1: value1, key2: value2, … ]. So in the above example there is a map of type Map<Integer, Closure> with three entries, which sure beats having to use new HashMap().

The values of the map are Closures, which are function objects. The closure can be executed and passed arguments just like formal methods. They can also be passed around to other methods, returned from methods, and assigned to fields. Very, very powerful. Think of them as Runnable or Callable objects without the awful syntax.

Finally, the each method is just a method on Collections and Maps that iterates over the collection, executing the attached closure once for every element. You can see how this closure runs a simple assertion, asserting that the integer key of the map equals the evaluated value of the map.

With a minimum of non-essentials, this test creates a dataset to be used as test input and then executes the test against that input; it is a data driver test, without a framework, without needing to hide any of the mechanics of the test, and without a bunch of annotations and factory methods. Data driven tests are so easy to write in Groovy that you end up using them far more often than in Java.

Listing 2 is another data driven test with a more useful assertion than simple arithmetic:

Java

1

2

3

4

5

6

7

8

9

10

11

publicvoidtestUserService(userService){

[user1:["John","Doe",123456],

user2:["Jane","Doe",654321],

user3:["John","Smith",789987],

].each{username,userData->

def user=userService.get(username)

assertuser.firstName==userData[0]

assertuser.lastName==userData[1]

assertuser.id==userData[2]

}

}

Listing 2: An Advanced Data Driven Test

This time the data is a map of Strings to a list of values (within Maps, unquoted key value are treated as Strings, so user1 and user2 are Strings). Java purists will notice that the generics of this expression are not easily expressed in Java, while they can be ignored in a dynamic language like Groovy. In this example the assertion block is simply pulling elements out of the list using the subscript operator [0] and [1] instead of the List#get(int) syntax.

The point is that the Groovy language features (list and map literals, closures, good iteration functions) allow you to write data driven tests more quickly, which in turn means you cover more edge cases and more failure scenarios as well. The minimal syntax of Groovy allows you to get down to the essence of a unit test: clearly show the input, execute the system, and clearly assert the output. Sure, you can Extract Method in Java until you have something with minimal accidental complexity (maybe even “extracting until you drop”), but as Alan Shalloway says, “There is a big difference between eliminating waste and not creating it in the first place.” With Groovy you will write tests faster and you will have your story cards spend less time in the “in process” phase. This is good for your project and good for your customers.

* “Extract Until You Drop” is a blog post from the inimitable Uncle Bob Martin about taking Extract Method refactorings to their logical, if absurd, conclusion. The piece could just have easily been titled, “Writing Clean Code in Java is a Complete Hassle”.

What happened to assertEquals?

Sure, using Groovy’s assert makes your tests more terse, but more importantly check out the exception message on a failing assertion in Listing 3.

Java

1

2

3

def one="1"

def two="2"

assertone+one==two

Listing 3: Groovy Assertions

Treating addition as String concatenation is endearing when your four-year-old is learning arithmetic but is an error in most mathematical systems. Listing 3 is interesting because of the exception message: each element of the expression is clearly expressed in the monospaced message: all three variable references as well as both the operators (+ and ==). Lower ceremony, clearer tests, easier debugging.

Next Steps

One particularly useful Lean practice for eliminating waste is Value Stream Mapping. Sit down at a whiteboard with your development team and write out your software process: the steps and time it takes to move an idea from inception to customer delivery. Where are the bottlenecks? What are the delays? Why does it take so long? Visualizing and quantifying your process helps everyone clearly see problem areas. And who knows, maybe a few Groovy scripts here and there can cut days out of your cycle. Stranger things have happened.

Next Month: Build Quality In

A lean, stream-lined development cycle with minimal waste is nothing if quality suffers. Next month’s article explores how Groovy helps you build quality into your development life-cycle. Instead of inspecting your product for defects after it is built, change your process to not create the defects in the first place. Easier said then done. Luckily, Groovy programmers can use great tools and techniques like easyb, Behavior Driven Development, and builders to build quality into their products.

Learn More

The world is overflowing with books and articles about agile development. These three books are classics and deserve a permanent spot on the bookshelves of discerning programmers.

Implementing Lean Software Development – Poppendieck

The Pragmatic Programmer – Hunt and Thomas

Extreme Programming Explained, 2nd Edition – Beck and Anders

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.